Odoo portalai suteikia klientams ir partneriams prieigą prie aktualių dokumentų, sandorių ir paslaugų. Tai kelia tapatybės projektavimo klausimą: ar išoriniai naudotojai turėtų dalytis darbuotojų katalogu ir prieigos modeliu?
Kartais tinkama verslo svečio paskyra darbo jėgos tenante. Tačiau didesniu mastu, arba kai reikalingas firminis klientų prisijungimas ir savitarna registracijai, Microsoft Entra External ID suteikia dedikuotą klientų tapatybės ir prieigos valdymo modelį.
Šio modelio sujungimas su Odoo gali padėti aiškiau atskirti vidinius naudotojus ir portalo naudotojus. Vis tiek reikia aiškaus priėmimo, paskyros sukūrimo ir Odoo autorizacijos taisyklių.
Darbo jėgos ir išoriniai tenantai yra skirti skirtingoms auditorijoms
Microsoft darbo jėgos tenantą apibrėžia kaip aplinką darbuotojams, vidinėms verslo programoms ir organizacijos ištekliams. Jame taip pat gali būti pakviestų verslo partnerių ir svečių. Išorinis tenantas yra atskira konfigūracija programoms, skirtoms vartotojams ir verslo klientams. Microsoft šį skirtumą aprašo savo tenantų konfigūravimo gairėse.
Išorinis tenantas turi savo klientų katalogą ir programų registracijas. External ID prideda savitarnos registraciją, prisijungimą, slaptažodžio atkūrimą, paskyros valdymą ir tapatybės tiekėjų federaciją. External ID apžvalga paaiškina šį dedikuotą modelį.
Šis atskyrimas gali padėti organizacijai nevertinti kliento kaip darbuotojo vien todėl, kad abiem reikia prieigos prie Odoo paslaugos.
Prieš konfigūruodami prisijungimą, pasirinkite auditoriją
Reikia įvertinti bent tris skirtingas Odoo auditorijas:
Darbuotojai ir vidiniai naudotojai
Šie naudotojai paprastai priklauso organizacijos darbo jėgos tenantui. Jei jie įleidžiami į Odoo, jiems paprastai reikia vidinių Odoo naudotojo paskyrų su kruopščiai priskirtomis prieigos grupėmis.
Žmonės iš patvirtintų partnerių organizacijų
Kai kurios įmonės nori naudotojų iš apibrėžto klientų arba partnerių Entra tenantų sąrašo. Daugiafunkcis darbo jėgos ryšys su tiksliu leistinų tenantų sąrašu gali būti tinkamas, kai kiekviena organizacija yra žinoma ir prieiga patvirtinta sutartimi.
Tenanto patvirtinimas yra kritiškai svarbus. Vien el. pašto domeno atitikimo nepakanka, nes domenai ir el. pašto adresai gali keistis. Tikrinkite žetono tenantą ir nekintančius subjekto arba objekto identifikatorius pagal ryšio dizainą.
Klientai ir išoriniai naudotojai
Klientams skirtoms programoms External ID tenantas gali suteikti atskirą katalogą ir prisijungimo patirtį. Odoo paskyros, sukurtos šiai auditorijai, paprastai turėtų būti portalo naudotojai, o ne vidiniai naudotojai.
Šie modeliai turėtų būti sukonfigūruoti kaip atskiri ryšiai, kai jų priėmimo ir Odoo paskyrų taisyklės skiriasi. Vienas platus ryšys yra sunkiau suprantamas ir lengviau neteisingai sukonfigūruojamas.
External ID palaiko klientų prisijungimo kelią
External ID naudotojų srautai apibrėžia klientų autentifikavimo metodus ir registracijos metu surenkamą informaciją. Srautas susiejamas su registruotomis programomis, kad būtų įjungta registracija ir prisijungimas. Microsoft tai dokumentuoja pridedant programą prie External ID naudotojų srauto.
External ID gali palaikyti vietines paskyras ir federaciją su tapatybės teikėjais, įskaitant Microsoft Entra ID ir pasirinktinius OpenID Connect teikėjus. Registracijos metu galima rinkti įtaisytus ir pasirinktinius atributus, kaip aprašyta Microsoft klientų atributų gairėse.
Rinkite tik tokią informaciją, kurios Odoo iš tiesų reikia, ir dokumentuokite kiekvieno atributo paskirtį, saugojimo laiką bei privatumo tvarkymą.
Numatytosios teisės padeda išlaikyti atskyrimą
Microsoft nurodo, kad išorinio tenanto naudotojai pradeda su ribotomis numatytosiomis teisėmis. Paprastai jie gali pasiekti programas ir tvarkyti savo profilį, bet negauna plačių katalogo administravimo teisių. Žr. numatytąsias teises išoriniuose tenantuose.
Tas katalogo ribojimas automatiškai nesukonfigūruoja Odoo portalo teisių. Odoo vis tiek valdo, kokius įrašus portalo naudotojas gali matyti, naudodamas savo prieigos teises ir įrašų taisykles. Išbandykite portalo patirtį su reprezentatyviais klientų įrašais ir daugiau nei viena įmone ar paskyra, kad įsitikintumėte, jog duomenys atskirti tinkamai.
Nesuteikite naujai sukurtam išoriniam naudotojui vidinio Odoo naudotojo statuso, nebent yra atskiras, patvirtintas verslo procesas.
Naudokite modernų, patvirtintą OpenID Connect srautą
Microsoft palaiko OAuth 2.0 autorizavimo kodo srautą su Proof Key for Code Exchange ir OpenID Connect serverinėms žiniatinklio programoms. Jos autorizavimo kodo srauto dokumentacija aprašo šį palaikomą derinį.
OIDC išplečia OAuth 2.0 autentifikacijai. Microsoft skelbia aptikimo metaduomenis, galinių taškų informaciją ir viešuosius pasirašymo raktus. Ji taip pat rekomenduoja tikrinti grąžintą žetoną ir nonce, kad būtų sumažinta atkūrimo rizika. Žr. OpenID Connect Microsoft tapatybės platformoje.
Saugi integracija turėtų patikrinti laukiamą leidėją, auditoriją, parašą, tenanto kontekstą ir nonce. PKCE nepakeičia žetono tikrinimo, tikslios grįžimo konfigūracijos, TLS ar kliento paslapties apsaugos.
Bazinis prisijungimas gali prašyti standartinių OIDC apimčių, tokių kaip openid, profile ir email. Microsoft nurodo, kad šios apimtys yra talpinamos Microsoft Graph ir rekomenduoja prašyti tik tų teisių, kurių programai reikia. Žr. Microsoft tapatybės platformos apimtys. Todėl tikslus produkto teiginys yra „nėra didelių privilegijų Microsoft Graph API teisių standartiniam prisijungimui“, o ne bendras teiginys, kad Graph nedalyvauja.
Nuspręskite, kaip išoriniai naudotojai pasieks Odoo
Prieš įjungdami pirmą prisijungimą, apibrėžkite:
- Ar savarankiška registracija yra atvira, ar reikalingas patvirtinimas.
- Kurie tenantai arba tapatybės teikėjai yra leidžiami.
- Ar esamą Odoo portalo paskyrą galima susieti.
- Kuris nekintamas Microsoft identifikatorius saugomas po susiejimo.
- Kuriam Odoo įmonės ir partnerio įrašui priklauso naudotojas.
- Kokios portalų grupės ir įrašų taisyklės taikomos.
- Kas nutinka, kai prieiga atšaukiama.
- Kaip panaikinama aktyvi Odoo sesija.
Automatinis paskyros sukūrimas gali sumažinti administravimą, tačiau jis turėtų įvykti tik tada, kai tapatybė atitinka ryšio priėmimo taisykles. Sėkmingas Microsoft autentifikavimas patvirtina priimtinos tapatybės kontrolę. Tačiau pats savaime jis neįrodo, kad asmuo turėtų matyti konkretaus kliento Odoo įrašus.
Suplanuokite klientų aptarnavimą ir atkūrimą
Išoriniai naudotojai gali neturėti vidinės pagalbos tarnybos. Paskelbkite pagalbos kanalą ir nurodykite, kas valdo tapatybę. Išbandykite slaptažodžio nustatymo iš naujo, atkūrimo, nuomotojo pašalinimo ir pakeisto el. pašto scenarijus. Saugokite diagnostinius įvykius naudingus, bet nuasmenintus.
Jei jūsų neatidėliotinas poreikis yra darbuotojų prieiga, skaitykite kodėl turėtumėte apsaugoti savo Odoo instanciją su Microsoft SSO. Vidinėms teisėms žr. Odoo prieigos centralizavimą su Entra grupėmis ir programų vaidmenimis.
Prijunkite išorines auditorijas prie Odoo 19
Mūsų Microsoft Entra SSO for Odoo modulis palaiko atskirus darbuotojų, patvirtintų organizacijų ir Microsoft Entra External ID klientų auditorijų ryšius. External ID ryšiai pagal numatymą sukuria portalų naudotojus, o darbuotojų ryšiai sukuria vidinius naudotojus. Vedama sąranka patvirtina aptikimo informaciją ir pasirašymo raktus, tada prieš įjungiant Microsoft prisijungimą reikalauja interaktyvaus testo.
Modulis nenusprendžia, kas turėtų būti priimtas ar kokius kliento įrašus jie turėtų matyti. Tai išlieka verslo ir Odoo prieigos sprendimai. Peržiūrėkite modulį, jei jums reikia valdomo tilto tarp Microsoft kliento tapatybės ir Odoo 19 portalo, su auditorijai pritaikytu paskyrų valdymu, o ne vienu nediferencijuotu prisijungimo keliu.