Vienkartinis prisijungimas atsako į autentifikavimo klausimą: ar Microsoft patvirtino šį naudotoją pagal organizacijos politiką? Jis neatsako į visus autorizavimo klausimus pačiame Odoo.
Autentifikuotam naudotojui gali reikėti prieigos prie pardavimų, bet ne prie apskaitos, projektų, bet ne prie darbo užmokesčio, arba prie klientų portalo, bet ne prie vidinės sąsajos. Šiuos sprendimus vis tiek priima Odoo. Microsoft Entra grupės ir programų rolės gali suteikti patikimų įvesties duomenų, kad jie būtų nuoseklesni.
Grupės ir programų rolės atlieka skirtingas funkcijas
Microsoft Entra grupės priklauso nuomotojui. Jos gali atstovauti padaliniams, pareigoms, projektams arba saugumo riboms. Programų rolės priklauso konkrečiai programos registracijai ir aprašo tai programai prasmingas roles.
Microsoft programų rolių dokumentacija aiškina, kad programų rolės gali būti priskirtos naudotojams arba grupėms. Kai priskirtas naudotojas prisijungia, Entra gali į roles claim įtraukti suteiktas roles. Microsoft taip pat nurodo, kad programų rolės ir grupės nėra tarpusavyje nesuderinamos.
Tai suteikia Odoo prieigos dizainui du pagrindinius modelius:
- Tiesiogiai susiekite stabilius Entra saugos grupės Object ID su pasirinktomis Odoo grupėmis.
- Entra programoje apibrėžkite į Odoo orientuotas programų roles, priskirkite jas naudotojams arba grupėms ir susiekite gautas rolių reikšmes su Odoo grupėmis.
Tiesioginis susiejimas gerai veikia su valdomomis saugos grupėmis. Programų rolės gali suteikti aiškesnę programos ribą, nes jų paskirtis yra susieta su programos registracija, o ne su nuo nuomotojo priklausančiais pavadinimais.
Pradėkite nuo faktinio Odoo prieigos modelio
Nepradėkite kopijuodami kiekvieną Microsoft grupę į Odoo. Pradėkite nuo tų Odoo teisių, kurių verslui iš tikrųjų reikia.
Išvardykite Odoo grupes, kurios suteikia reikšmingas galimybes. Kiekvienai jų užfiksuokite:
- Verslo paskirtį, dėl kurios suteikiama prieiga.
- Asmenį, atsakingą už jos patvirtinimą.
- Entra grupę arba programos rolę, kuri reiškia patvirtinimą.
- Kaip greitai pakeitimas turėtų pasiekti Odoo ir kas nutinka aktyviai sesijai po pašalinimo.
Taikykite mažiausių privilegijų principą. Plati padalinio grupė gali būti patogi, bet ji gali suteikti daugiau Odoo prieigos, nei reikia kiekvienam nariui. Mažesnę Odoo specifinę saugos grupę arba programos rolę dažnai lengviau audituoti.
Tapatybės susiejimą laikykite saugumo kontrole
Daugelis sistemų iš pradžių esamą paskyrą sutapatina pagal el. pašto adresą. Tai patogu, ypač kai Odoo ir Microsoft jau naudoja tą patį įmonės el. paštą. Tai nėra ilgaamžis tapatybės raktas.
Microsoft savo ID token claims nuorodoje įspėja, kad el. pašto adresai, telefono numeriai ir naudotojo pagrindiniai vardai gali keistis ir gali būti pakartotinai naudojami. Patikimam identifikavimui Microsoft rekomenduoja nekintamus claim, tokius kaip sub arba oid, o kai reikalingas nuomotojo kontekstas, ir tid.
Saugesnis modelis yra toks:
- Leisti tik tikėtiną nuomotoją ir patvirtintą auditoriją.
- Kai tinka, naudoti el. paštą kontroliuojamam pirmam sutapdinimui.
- Atmesti dviprasmiškus arba pasikartojančius sutapimus.
- Po susiejimo saugoti nekintamus Microsoft tapatybės ir nuomotojo identifikatorius.
- Naudoti šias nekintamas reikšmes būsimiems prisijungimams.
Naudojant kelių nuomotojų prieigą, nuomotojo kontekstas yra būtinas. Tas pats asmuo skirtinguose nuomotojuose gali turėti skirtingus objekto identifikatorius, o prieiga iš vieno nuomotojo neturėtų tyliai paveldėti su kitu susijusių teisių.
Supraskite grupės claim perviršio atvejį
Group claims yra patogu, bet ne neriboti. Microsoft dokumentuoja 200 grupės Object ID ribą JWT. Kai naudotojo narystė viršija šią ribą, Entra neįtraukia įprasto grupių sąrašo ir pateikia perviršio indikatorių, kuris nukreipia programą užklausti Microsoft Graph. Žr. grupių perviršio gaires.
Tai svarbu, jei integracija skelbia grupių susiejimą neturėdama padidintų Microsoft Graph API teisių. Naudotojas, turintis daug grupių narystės, gali negauti laukiamo grupės claim rinkinio.
Prieš remdamiesi tiesioginiu grupių susiejimu, patikrinkite, kaip tvarkomas perviršis. Galimi variantai: mažesnės programai skirtos grupės, programų rolės, claim filtravimas arba Graph pagrįsta paieška su mažiausių privilegijų sutikimu.
Sinchronizavimas prisijungimo metu nėra tikro laiko aprovisionavimas
SSO modulis gali palyginti dabartinius Entra claim su sukonfigūruotais Odoo susiejimais, kai naudotojas prisijungia. Tai naudinga, nes prieiga gali būti suderinta įprasto autentifikavimo įvykio metu.
Tai nėra tas pats, kas nuolatinis aprovisionavimas. Jei darbuotojas pašalinamas iš Entra grupės, kol Odoo sesija aktyvi, ta sesija gali tęstis iki atsijungimo, galiojimo pabaigos arba kol bus pritaikyta kita atšaukimo kontrolė. Jei buvęs darbuotojas daugiau niekada neprisijungia, prisijungimo sinchronizavimo procesas pats savaime Odoo paskyros nearchyvuoja.
Microsoft Entra ID Governance siūlo Lifecycle Workflows darbuotojų įdarbinimo, perkėlimo ir išėjimo procesams, įskaitant paskyrų išjungimą ir prieigos priskyrimų pašalinimą. Žr. Microsoft Lifecycle Workflows gaires. Šioms galimybėms reikalinga Microsoft Entra ID Governance arba Microsoft Entra Suite licencija.
Gyvavimo ciklo automatizavimas gali pagerinti šaltinio tapatybės būseną, bet vis tiek neatnaujins Odoo, jei integracija neapdoros pakeitimo. Jūsų išėjimo iš darbo procedūra turėtų aiškiai apimti Odoo sesijos atšaukimą ir paskyros būseną.
Sukurkite audituojamą susiejimo modelį
Laikykite susiejimų skaičių suprantamą. Kiekvienai grupei ar rolei naudokite stabilų identifikatorių ir žmonėms suprantamą aprašą. Užfiksuokite, kodėl susijusi Odoo prieiga egzistuoja, kas ją patvirtino ir kada ji paskutinį kartą buvo peržiūrėta.
Išbandykite bent šiuos atvejus:
- Esamas naudotojas su vienu tikėtinu susiejimu.
- Naudotojas be patvirtinto susiejimo arba iš neleistino nuomotojo.
- Naujas naudotojas, leidžiamas pirmajam prisijungimui.
- Naudotojas, pašalintas iš susietos grupės arba turintis daug grupių narystės.
- Pervadintas naudotojas, kurio nekintama tapatybė nepasikeitė.
- Išjungta Microsoft paskyra su esama Odoo sesija.
Prisijungimo įvykiai turėtų padėti administratoriams diagnozuoti teiginių ir susiejimo rezultatus neatskleidžiant žetonų, prisijungimo duomenų ar paslapčių. Žurnaluose turėtų būti identifikuojamas ryšys ir rezultatas, tačiau jautrios reikšmės turėtų būti užmaskuotos.
Sujunkite susiejimą su autentifikavimo politika
Grupių ir vaidmenų susiejimas valdo Odoo autorizaciją. Microsoft Entra Conditional Access valdo, ar Microsoft užbaigs autentifikavimą esamomis sąlygomis. Šie du sluoksniai vienas kitą papildo.
Pavyzdžiui, Entra programos vaidmuo gali būti susietas su Odoo finansų grupe, o Conditional Access gali reikalauti apsaugos nuo sukčiavimo atsparaus autentifikavimo stiprumo vartotojams, priskirtiems tam vaidmeniui. Skaitykite kaip Microsoft Entra Conditional Access sustiprina Odoo prisijungimą autentifikavimo politikos pusei.
Klientams ir partneriams nenaudokite darbuotojų susiejimų automatiškai. Atskiros auditorijos ir portalui pritaikytas dizainas gali būti saugesnis. Žr. Microsoft Entra External ID for Odoo customers and partners.
Susiekite patvirtintą Microsoft prieigą su Odoo 19
Mūsų Microsoft Entra SSO for Odoo module palaiko sukonfigūruotų Entra saugos grupių Object ID arba programos vaidmenų susiejimą su pasirinktomis Odoo prieigos grupėmis. Jis gali sinchronizuoti šiuos susiejimus prisijungimo metu, susieti kontroliuojamą esamą paskyrą ir kurti patvirtintus darbuotojų arba portalo vartotojus pagal ryšio tipą.
Modulis nepakeičia prieigos valdymo, sesijos atšaukimo ar dokumentuotos pertekliaus strategijos. Prieš įgalindami susiejimus, peržiūrėkite grupių mastą, tapatybės susiejimo reikalavimus ir Odoo teisių modelį. Jei šie pagrindai aiškūs, modulis suteikia patogų būdą juos sujungti.