Single sign-on odgovara na pitanje autentifikacije: da li je Microsoft potvrdio ovog korisnika prema politici organizacije? Ne odgovara na svako pitanje autorizacije unutar Odoo-a.
Autentifikovanom korisniku možda je potreban pristup prodaji, ali ne i računovodstvu, projektima, ali ne i obračunu zarada, ili korisničkom portalu, ali ne i internom interfejsu. Te odluke ostaju odgovornost Odoo-a. Microsoft Entra grupe i aplikacione uloge mogu da obezbede pouzdane ulaze za njihovo doslednije donošenje.
Grupe i app uloge služe različitim svrhama
Microsoft Entra grupe pripadaju tenant-u. One mogu predstavljati odeljenja, funkcije poslova, projekte ili bezbednosne granice. Aplikacione uloge pripadaju određenoj registraciji aplikacije i opisuju uloge koje imaju značenje za tu aplikaciju.
Microsoftova dokumentacija o app ulogama objašnjava da se app uloge mogu dodeliti korisnicima ili grupama. Kada prijavljeni korisnik pristupi sistemu, Entra može da uključi dodeljene uloge u claims roles. Microsoft takođe navodi da app uloge i grupe nisu međusobno isključive.
To daje dva glavna obrasca za dizajn Odoo pristupa:
- Mapirajte stabilne Entra security-group Object ID-jeve direktno na odabrane Odoo grupe.
- Definišite app uloge fokusirane na Odoo u Entra aplikaciji, dodelite korisnike ili grupe tim ulogama i mapirajte dobijene vrednosti uloga na Odoo grupe.
Direktno mapiranje dobro funkcioniše sa upravljanim bezbednosnim grupama. App uloge mogu da obezbede čistiju granicu aplikacije jer njihova namera putuje sa registracijom aplikacije, umesto da zavisi od naziva specifičnih za tenant.
Krenite od stvarnog Odoo modela pristupa
Nemojte počinjati tako što ćete kopirati svaku Microsoft grupu u Odoo. Počnite od Odoo dozvola koje poslovanje zaista treba.
Navedite Odoo grupe koje daju značajne mogućnosti. Za svaku dokumentujte:
- Poslovnu svrhu pristupa.
- Osobu odgovornu za odobravanje.
- Entra grupu ili app ulogu koja predstavlja odobrenje.
- Koliko brzo promena treba da stigne do Odoo-a i šta se dešava sa aktivnom sesijom nakon uklanjanja.
Koristite princip najmanjih privilegija. Široka grupa odeljenja može biti praktična, ali može da dodeli više Odoo pristupa nego što je svakom članu potrebno. Manja Odoo-specifična bezbednosna grupa ili app uloga često je lakša za reviziju.
Vežite identitet kao bezbednosnu kontrolu
Mnogi sistemi u početku usklađuju postojeći nalog pomoću email adrese. To je praktično, naročito kada Odoo i Microsoft već koriste istu korporativnu email adresu. To nije trajni identifikator identiteta.
Microsoft upozorava u svojoj referenci za ID token claims da se email adrese, brojevi telefona i user principal name vrednosti mogu menjati i ponovo koristiti. Microsoft preporučuje nepromenljive claims, kao što su sub ili oid, uz tid kada je potreban tenant kontekst, za pouzdanu identifikaciju.
Bezbedniji obrazac je:
- Dozvolite samo očekivani tenant i odobrenu audience vrednost.
- Koristite email za kontrolisano prvo usklađivanje, gde je primenljivo.
- Odbijte dvosmislena ili duplikatna podudaranja.
- Sačuvajte nepromenljivi Microsoft identitet i identifikatore tenant-a nakon povezivanja.
- Koristite te nepromenljive vrednosti za buduća prijavljivanja.
Za pristup u više tenant-a, tenant kontekst je presudan. Ista osoba može imati različite object ID-jeve u različitim tenant-ima, a pristup iz jednog tenant-a ne bi trebalo tiho da nasleđuje dozvole povezane sa drugim.
Razumite slučaj prekomernog broja group claim-ova
Group claim-ovi su praktični, ali nisu neograničeni. Microsoft dokumentuje ograničenje od 200 group Object ID-jeva u JWT-u. Kada članstvo korisnika premaši to ograničenje, Entra izostavlja uobičajenu listu grupa i vraća indikator prekomernog broja koji usmerava aplikaciju da upita Microsoft Graph. Pogledajte smernice za prekomerni broj grupa.
To je važno ako integracija oglašava mapiranje grupa bez povišenih Microsoft Graph API dozvola. Korisnik sa velikim brojem članstava u grupama možda neće dobiti očekivani skup group claim-ova.
Pre nego što se oslonite na direktno mapiranje grupa, potvrdite kako se obrađuje prekomerni broj. Opcije uključuju manje app-specifične grupe, app uloge, filtriranje claim-ova ili Graph-based lookup sa najmanjim mogućim consent-om.
Sinhronizacija pri prijavljivanju nije provisionovanje u realnom vremenu
SSO modul može da uporedi trenutne Entra claim-ove sa konfigurisanim Odoo mapiranjima kada se korisnik prijavi. To je korisno jer se pristup može uskladiti tokom uobičajenog događaja autentifikacije.
To nije isto što i kontinuirano provisionovanje. Ako je zaposleni uklonjen iz Entra grupe dok je Odoo sesija aktivna, ta sesija može da traje do odjave, isteka ili primene drugog mehanizma opoziva. Ako bivši zaposleni nikada više ne pristupi sistemu, proces sinhronizacije pri prijavljivanju sam po sebi neće arhivirati Odoo nalog.
Microsoft Entra ID Governance nudi Lifecycle Workflows za joiner, mover i leaver procese, uključujući onemogućavanje naloga i uklanjanje dodela pristupa. Pogledajte Microsoftove smernice za Lifecycle Workflows. Ove mogućnosti zahtevaju Microsoft Entra ID Governance ili Microsoft Entra Suite licenciranje.
Automatizacija životnog ciklusa može poboljšati stanje izvornog identiteta, ali i dalje ne ažurira Odoo osim ako integracija ne obradi tu promenu. Vaša procedura za offboarding treba eksplicitno da obuhvati opoziv Odoo sesije i stanje naloga.
Izgradite auditable model mapiranja
Održavajte broj mapiranja razumljivim. Za svaku grupu ili ulogu koristite stabilan identifikator i opis razumljiv ljudima. Zabeležite zašto povezani Odoo pristup postoji, ko ga je odobrio i kada je poslednji put pregledan.
Testirajte bar ove slučajeve:
- Postojeći korisnik sa jednim očekivanim mapiranjem.
- Korisnik bez odobrenog mapiranja ili sa nedozvoljenim tenant-om.
- Novi korisnik dopušten za prvo prijavljivanje.
- Korisnik uklonjen iz mapirane grupe ili sa velikim brojem članstava u grupama.
- Preimenovani korisnik čiji nepromenljivi identitet nije promenjen.
- Onemogućeni Microsoft nalog sa postojećom Odoo sesijom.
Događaji prijavljivanja treba da pomognu administratorima da dijagnostikuju ishode tvrdnji i mapiranja bez izlaganja tokena, kredencijala ili tajni. Evidencije treba da identifikuju vezu i rezultat, ali osetljive vrednosti treba da budu prikrivene.
Kombinujte mapiranje sa pravilima autentifikacije
Kontrole mapiranja grupa i uloga upravljaju Odoo autorizacijom. Microsoft Entra Conditional Access kontroliše da li će Microsoft dovršiti autentifikaciju pod trenutnim uslovima. Ova dva sloja se dopunjuju.
Na primer, Entra aplikaciona uloga može da se mapira na Odoo finansijsku grupu, dok Conditional Access zahteva autentifikaciju otpornu na fišing za korisnike dodeljene toj ulozi. Pročitajte kako Microsoft Entra Conditional Access jača Odoo prijavljivanje na strani pravila autentifikacije.
Za korisnike i partnere, nemojte automatski ponovo koristiti mapiranja zaposlenih. Poseban pristup i dizajn usmeren na portal mogu biti bezbedniji. Pogledajte Microsoft Entra External ID za Odoo korisnike i partnere.
Mapirajte odobreni Microsoft pristup u Odoo 19
Naš Microsoft Entra SSO for Odoo module podržava mapiranje konfigurisanih Entra Object ID-jeva bezbednosnih grupa ili aplikacionih uloga na izabrane Odoo pristupne grupe. Može da sinhronizuje ta mapiranja pri prijavljivanju, poveže kontrolisani postojeći nalog i kreira odobrene korisnike za zaposlene ili portal, u skladu sa tipom veze.
Modul ne zamenjuje upravljanje pristupom, opoziv sesije niti dokumentovanu strategiju za višak. Pregledajte veličinu svojih grupa, zahteve za povezivanje identiteta i Odoo model dozvola pre omogućavanja mapiranja. Ako su ti temelji jasni, modul pruža vođen način da ih povežete.