Enotna prijava odgovori na vprašanje avtentikacije: ali je Microsoft tega uporabnika preveril v skladu s politiko organizacije? Ne odgovori pa na vsako vprašanje avtorizacije znotraj Odoo.
Avtenticiran uporabnik morda potrebuje dostop do prodaje, ne pa do računovodstva, do projektov, ne pa do plač, ali pa do portal za stranke, ne pa do notranjega vmesnika. Te odločitve ostajajo odgovornost Odoo. Skupine Microsoft Entra in vloge aplikacij lahko zagotovijo zaupanja vredne vhodne podatke, da so te odločitve bolj dosledne.
Skupine in vloge aplikacij služijo različnim namenom
Skupine Microsoft Entra pripadajo najemniku. Lahko predstavljajo oddelke, delovne funkcije, projekte ali varnostne meje. Vloge aplikacij pripadajo določeni registraciji aplikacije in opisujejo vloge, ki so pomembne za to aplikacijo.
Microsoftova dokumentacija o vlogah aplikacij pojasnjuje, da se vloge aplikacij lahko dodelijo uporabnikom ali skupinam. Ko se dodeljeni uporabnik prijavi, lahko Entra v zahtevek roles vključi dodeljene vloge. Microsoft tudi navaja, da vloge aplikacij in skupine niso medsebojno izključujoče.
To za zasnovo dostopa do Odoo prinaša dva glavna vzorca:
- Stabilne Object ID-je varnostnih skupin Entra neposredno preslikajte na izbrane skupine Odoo.
- V aplikaciji Entra definirajte vloge aplikacij, usmerjene v Odoo, dodelite uporabnike ali skupine tem vlogam in nastale vrednosti vlog preslikajte v skupine Odoo.
Neposredna preslikava dobro deluje z upravljanimi varnostnimi skupinami. Vloge aplikacij lahko zagotovijo čistejšo mejo aplikacije, ker je njihov namen vezan na registracijo aplikacije, ne pa na imena, odvisna od najemnika.
Začnite z dejanskim modelom dostopa Odoo
Ne začnite s kopiranjem vsake skupine Microsoft v Odoo. Začnite s pravicami Odoo, ki jih podjetje dejansko potrebuje.
Naštejte skupine Odoo, ki dodeljujejo pomembne zmožnosti. Za vsako dokumentirajte:
- Poslovni namen dostopa.
- Osebo, odgovorno za odobritev.
- Skupino Entra ali vlogo aplikacije, ki predstavlja odobritev.
- Kako hitro naj sprememba doseže Odoo in kaj se zgodi z aktivno sejo po odstranitvi.
Uporabite načelo najmanjših privilegijev. Široka skupina oddelka je morda priročna, vendar lahko dodeli več dostopa do Odoo, kot ga potrebuje vsak član. Manjša varnostna skupina ali vloga aplikacije, specifična za Odoo, je pogosto lažja za revizijo.
Povezovanje identitete obravnavajte kot varnostni nadzor
Mnogi sistemi najprej ujemajo obstoječi račun z uporabo e-poštnega naslova. To je priročno, zlasti ko Odoo in Microsoft že uporabljata isti službeni e-poštni naslov. To pa ni trajen identifikator identitete.
Microsoft opozarja v svojem referenčnem gradivu za zahtevke ID žetonov da se e-poštni naslovi, telefonske številke in uporabniška principal imena lahko spremenijo in ponovno uporabijo. Microsoft za zanesljivo identifikacijo priporoča nespremenljive zahtevke, kot sta sub ali oid, z tid, kjer je potreben kontekst najemnika.
Varnejši vzorec je:
- Dovolite samo pričakovani najemnik in odobreno občinstvo.
- Uporabite e-pošto za nadzorovano prvo ujemanje, kjer je primerno.
- Zavrnite dvoumna ali podvojena ujemanja.
- Po povezavi shranite nespremenljivi identifikator Microsoftove identitete in identifikator najemnika.
- Te nespremenljive vrednosti uporabite za prihodnje prijave.
Za dostop v več najemnikih je kontekst najemnika bistven. Ista oseba ima lahko v različnih najemnikih različne identifikatorje objektov, dostop iz enega najemnika pa ne sme tiho podedovati pravic, povezanih z drugim.
Razumite primer presežka zahtevkov za skupine
Zahtevki za skupine so priročni, vendar niso neomejeni. Microsoft dokumentira omejitev 200 Object ID-jev skupin v JWT. Ko članstvo uporabnika preseže omejitev, Entra izpusti običajen seznam skupin in vrne indikator presežka, ki aplikacijo usmeri na poizvedbo v Microsoft Graph. Glejte smernice za presežek skupin.
To je pomembno, če integracija oglašuje preslikavo skupin brez povišanih dovoljenj za Microsoft Graph API. Uporabnik z obsežnim članstvom v skupinah morda ne bo prejel pričakovanega nabora zahtevkov skupin.
Preden se zanesete na neposredno preslikavo skupin, preverite, kako je obravnavan presežek. Možnosti vključujejo manjše aplikacijsko specifične skupine, vloge aplikacij, filtriranje zahtevkov ali poizvedbo prek Graph z dovoljenjem najmanjših privilegijev.
Sinhronizacija ob prijavi ni omogočanje v realnem času
SSO modul lahko ob prijavi uporabnika primerja trenutne zahtevke Entra s konfiguriranimi preslikavami Odoo. To je uporabno, ker je mogoče dostop uskladiti med običajnim dogodkom avtentikacije.
To ni isto kot neprekinjeno omogočanje. Če je zaposleni med aktivno sejo Odoo odstranjen iz skupine Entra, lahko seja ostane aktivna do odjave, poteka ali uporabe drugega nadzora preklica. Če nekdanji zaposleni nikoli več ne opravi prijave, postopek sinhronizacije ob prijavi sam po sebi ne arhivira računa Odoo.
Microsoft Entra ID Governance ponuja Lifecycle Workflows za procese joiner, mover in leaver, vključno z onemogočanjem računov in odstranjevanjem dodelitev dostopa. Glejte Microsoftove smernice za Lifecycle Workflows. Te zmožnosti zahtevajo licenciranje Microsoft Entra ID Governance ali Microsoft Entra Suite.
Avtomatizacija življenjskega cikla lahko izboljša stanje izvorne identitete, vendar še vedno ne posodobi Odoo, razen če integracija spremembo dejansko uporabi. Vaš postopek izključitve mora izrecno zajemati preklic seje Odoo in stanje računa.
Zgradite revizijsko sledljiv model preslikav
Število preslikav naj bo razumljivo. Za vsako skupino ali vlogo uporabite stabilen identifikator in opis, ki ga je mogoče prebrati. Zabeležite, zakaj povezan dostop Odoo obstaja, kdo ga je odobril in kdaj je bil nazadnje pregledan.
Preizkusite vsaj te primere:
- Obstoječi uporabnik z eno pričakovano preslikavo.
- Uporabnik brez odobrene preslikave ali z nedovoljenim najemnikom.
- Nov uporabnik, sprejet za prvo prijavo.
- Uporabnik odstranjen iz preslikane skupine ali z mnogimi članstvi v skupinah.
- Preimenovan uporabnik, katerega nespremenljiva identiteta se ni spremenila.
- Onemogočen račun Microsoft z obstoječo sejo Odoo.
Dogodki prijave bi morali skrbnikom pomagati pri diagnosticiranju izidov zahtevkov in preslikav, ne da bi razkrivali žetone, poverilnice ali skrivnosti. Dnevniki naj prepoznajo povezavo in rezultat, občutljive vrednosti pa naj bodo prikrite.
Združite preslikavo s politiko preverjanja pristnosti
Kontrole preslikave skupin in vlog upravljajo avtorizacijo v Odoo. Microsoft Entra Conditional Access določa, ali bo Microsoft dokončal preverjanje pristnosti v trenutnih pogojih. Obe plasti se dopolnjujeta.
Na primer, vloga aplikacije Entra se lahko preslika v finančno skupino Odoo, medtem ko Conditional Access za uporabnike, dodeljene tej vlogi, zahteva odpornost na ribarjenje pri moči preverjanja pristnosti. Preberite kako Microsoft Entra Conditional Access krepi prijavo v Odoo za stran politike preverjanja pristnosti.
Za stranke in partnerje ne uporabljajte samodejno preslikav zaposlenih. Ločen pristop za ciljno skupino in portalno usmerjen dizajn je morda varnejši. Glejte Microsoft Entra External ID za stranke in partnerje Odoo.
Preslikajte odobren Microsoftov dostop v Odoo 19
Naš Microsoft Entra SSO for Odoo module podpira preslikavo konfiguriranih varnostnih skupin Entra, Object ID-jev ali vlog aplikacij v izbrane skupine dostopa Odoo. Te preslikave lahko sinhronizira ob prijavi, poveže nadzorovan obstoječi račun in ustvari odobrene uporabnike za zaposlene ali portal glede na vrsto povezave.
Modul ne nadomešča upravljanja dostopa, preklica seje ali dokumentirane strategije za presežke. Pred omogočanjem preslikav preverite obseg skupin, zahteve za vezavo identitete in model dovoljenj Odoo. Če so te osnove jasne, modul ponuja voden način, da jih povežete.