Vienotā pierakstīšanās atbild uz autentifikācijas jautājumu: vai Microsoft ir pārbaudījis šo lietotāju saskaņā ar organizācijas politiku? Tā neatbild uz visiem autorizācijas jautājumiem Odoo iekšienē.
Autentificētam lietotājam var būt vajadzīga piekļuve pārdošanai, bet ne grāmatvedībai, projektiem, bet ne algām, vai klientu portālam, bet ne iekšējai saskarnei. Šie lēmumi joprojām ir Odoo atbildība. Microsoft Entra grupas un lietotņu lomas var nodrošināt uzticamus ievades datus, lai tos pieņemtu konsekventāk.
Grupām un lietotņu lomām ir atšķirīgi mērķi
Microsoft Entra grupas pieder nomniekam. Tās var attēlot nodaļas, amata funkcijas, projektus vai drošības robežas. Lietotņu lomas pieder konkrētai lietotnes reģistrācijai un apraksta lomas, kas ir nozīmīgas šai lietotnei.
Microsoft app-role dokumentācija skaidro, ka lietotņu lomas var piešķirt lietotājiem vai grupām. Kad piešķirts lietotājs pierakstās, Entra var iekļaut piešķirtās lomas roles pieprasījumā. Microsoft arī norāda, ka lietotņu lomas un grupas nav savstarpēji izslēdzošas.
Tas Odoo piekļuves dizainam dod divus galvenos modeļus:
- Kartējiet stabilus Entra drošības grupas Object ID tieši uz izvēlētām Odoo grupām.
- Definējiet Odoo orientētas lietotņu lomas Entra lietotnē, piešķiriet tās lietotājiem vai grupām un kartējiet iegūtās lomu vērtības uz Odoo grupām.
Tieša kartēšana labi darbojas ar pārvaldītām drošības grupām. Lietotņu lomas var nodrošināt skaidrāku lietotnes robežu, jo to nolūks seko lietotnes reģistrācijai, nevis ir atkarīgs no nomniekam specifiskiem nosaukumiem.
Sāciet ar Odoo faktisko piekļuves modeli
Nesāciet ar katras Microsoft grupas kopēšanu uz Odoo. Sāciet ar Odoo atļaujām, kas uzņēmumam patiešām ir vajadzīgas.
Uzskaitiet Odoo grupas, kas piešķir būtiskas iespējas. Katram no tām dokumentējiet:
- Piekļuves biznesa mērķi.
- Personu, kas ir atbildīga par tās apstiprināšanu.
- Entra grupu vai lietotņu lomu, kas attēlo apstiprinājumu.
- Cik ātri izmaiņai vajadzētu nonākt Odoo un kas notiek ar aktīvu sesiju pēc noņemšanas.
Izmantojiet vismazāko privilēģiju principu. Plaša nodaļas grupa var būt ērta, taču tā var piešķirt vairāk Odoo piekļuves, nekā vajag katram dalībniekam. Mazāka, Odoo specifiska drošības grupa vai lietotņu loma bieži ir vieglāk auditējama.
Identitātes sasaisti uzskatiet par drošības kontroli
Daudzas sistēmas sākotnēji salīdzina esošu kontu, izmantojot e-pasta adresi. Tas ir ērti, īpaši tad, ja Odoo un Microsoft jau izmanto vienu un to pašu korporatīvo e-pastu. Tas nav ilgtspējīgs identitātes atslēgas risinājums.
Microsoft savā ID token claims reference norāda, ka e-pasta adreses, tālruņa numuri un lietotāja galvenie vārdi var mainīties un var tikt atkārtoti izmantoti. Drošai identifikācijai Microsoft iesaka nemainīgus pieprasījumus, piemēram, sub vai oid, ar tid, ja nepieciešams nomnieka konteksts.
Drošāks modelis ir šāds:
- Pieņemiet tikai paredzētu nomnieku un apstiprinātu auditoriju.
- Izmantojiet e-pastu kontrolētai pirmreizējai salāgošanai, ja tas ir piemēroti.
- Noraidiet neskaidras vai dublikātu atbilstības.
- Pēc sasaistes saglabājiet nemainīgo Microsoft identitāti un nomnieka identifikatorus.
- Turpmākām pierakstīšanās reizēm izmantojiet šīs nemainīgās vērtības.
Daudznomnieku piekļuvei nomnieka konteksts ir būtisks. Vienai un tai pašai personai dažādos nomniekos var būt atšķirīgi objekta identifikatori, un piekļuve no viena nomnieka nedrīkst klusi pārmantot ar citu saistītās atļaujas.
Izprotiet grupu claims pārsnieguma gadījumu
Grupu claims ir ērti, bet tie nav neierobežoti. Microsoft dokumentē 200 grupu Object ID limitu JWT. Ja lietotāja dalība pārsniedz šo limitu, Entra neiekļauj parasto grupu sarakstu un atgriež pārsnieguma indikatoru, kas lietotni novirza uz Microsoft Graph vaicājumu. Skatiet groups overage guidance.
Tas ir svarīgi, ja integrācija sola grupu kartēšanu bez paaugstinātām Microsoft Graph API atļaujām. Lietotājs ar plašu grupu dalību var nesaņemt paredzēto grupu claims kopu.
Pirms paļauties uz tiešu grupu kartēšanu, pārbaudiet, kā tiek apstrādāts pārsniegums. Iespējas ietver mazākas lietotnei specifiskas grupas, lietotņu lomas, claims filtrēšanu vai Graph balstītu uzmeklēšanu ar vismazākās privilēģijas piekrišanu.
Sinhronizācija pierakstīšanās laikā nav reāllaika nodrošināšana
SSO modulis var salīdzināt pašreizējos Entra claims ar konfigurētajām Odoo kartēm, kad lietotājs pierakstās. Tas ir noderīgi, jo piekļuve var tikt saskaņota parastā autentifikācijas notikuma laikā.
Tas nav tas pats, kas nepārtraukta nodrošināšana. Ja darbinieks tiek noņemts no Entra grupas, kamēr Odoo sesija ir aktīva, šī sesija var turpināties līdz atteikšanās brīdim, derīguma termiņa beigām vai līdz tiek piemērots cits atsaukšanas kontroles mehānisms. Ja bijušais darbinieks vairs nekad nepierakstās, pierakstīšanās sinhronizācijas process pats par sevi Odoo kontu nearchivē.
Microsoft Entra ID Governance piedāvā Lifecycle Workflows pievienošanās, pārcelšanas un aiziešanas procesiem, tostarp kontu atspējošanai un piekļuves piešķīrumu noņemšanai. Skatiet Microsoft Lifecycle Workflows guidance. Šīm iespējām ir nepieciešama Microsoft Entra ID Governance vai Microsoft Entra Suite licence.
Dzīves cikla automatizācija var uzlabot avota identitātes stāvokli, taču tā joprojām neatjaunina Odoo, ja vien izmaiņu neizmanto integrācija. Jūsu darbinieka aiziešanas procedūrai skaidri jāaptver Odoo sesijas atsaukšana un konta statuss.
Izveidojiet auditējamu kartēšanas modeli
Saglabājiet saprotamu kartējumu skaitu. Katram grupas vai lomas ierakstam izmantojiet stabilu identifikatoru un cilvēkam saprotamu aprakstu. Reģistrējiet, kāpēc attiecīgā Odoo piekļuve pastāv, kas to apstiprināja un kad tā pēdējo reizi tika pārskatīta.
Pārbaudiet vismaz šādus gadījumus:
- Esošs lietotājs ar vienu paredzētu kartējumu.
- Lietotājs bez apstiprināta kartējuma vai ar neatļautu nomnieku.
- Jauns lietotājs, kas tiek pieņemts pirmajai pierakstīšanās reizei.
- Lietotājs, kas noņemts no kartētas grupas vai kam ir daudz grupu dalību.
- Pārdēvēts lietotājs, kura nemaināmā identitāte nav mainījusies.
- Atspējots Microsoft konts ar esošu Odoo sesiju.
Pierakstīšanās notikumiem vajadzētu palīdzēt administratoriem diagnosticēt apliecinājumu un kartēšanas rezultātus, neatklājot žetonus, akreditācijas datus vai slepenus datus. Žurnālos vajadzētu norādīt savienojumu un rezultātu, bet sensitīvās vērtības ir jānoņem.
Apvienojiet kartēšanu ar autentifikācijas politiku
Grupu un lomu kartēšana kontrolē Odoo autorizāciju. Microsoft Entra Conditional Access kontrolē, vai Microsoft pabeigs autentifikāciju pašreizējos apstākļos. Abi slāņi viens otru papildina.
Piemēram, Entra lietotnes loma var tikt kartēta ar Odoo finanšu grupu, savukārt Conditional Access pieprasa pret pikšķerēšanu izturīgu autentifikācijas stiprumu lietotājiem, kuriem piešķirta šī loma. Lasiet kā Microsoft Entra Conditional Access stiprina Odoo pierakstīšanos par autentifikācijas politikas pusi.
Klientiem un partneriem automātiski nepārlieciet darbinieku kartējumus. Atsevišķa auditorija un portālam vērsts dizains var būt drošāks. Skatiet Microsoft Entra External ID Odoo klientiem un partneriem.
Kartējiet apstiprinātu Microsoft piekļuvi Odoo 19
Mūsu Microsoft Entra SSO for Odoo modulis atbalsta konfigurētu Entra drošības grupu Object ID vai lietotņu lomu kartēšanu ar atlasītām Odoo piekļuves grupām. Tas var sinhronizēt šos kartējumus pierakstīšanās laikā, saistīt kontrolētu esošu kontu un izveidot apstiprinātus darbinieku vai portāla lietotājus atkarībā no savienojuma veida.
Modulis neaizstāj piekļuves pārvaldību, sesijas atsaukšanu vai dokumentētu pārsnieguma stratēģiju. Pirms kartējumu iespējošanas pārskatiet savu grupu apjomu, identitātes sasaistes prasības un Odoo atļauju modeli. Ja šie pamati ir skaidri, modulis nodrošina vadītu veidu, kā tos savienot.