Odoo bieži glabā informāciju, kas ir svarīga visai organizācijai: klientu ierakstus, pārdošanas aktivitātes, rēķinus, darbinieku datus, projektus, krājumus un operacionālos dokumentus. Piekļuve šai informācijai ir pelnījusi tādu pašu uzmanību kā piekļuve e-pastam, failiem un citām pamata biznesa sistēmām.

Tomēr Odoo var kļūt par identitātes salu. Darbiniekiem var būt viena parole Microsoft 365 un cita parole Odoo. Administratori var būt spiesti pārvaldīt piekļuvi atsevišķās vietās. Kad kāds maina amatu vai pamet uzņēmumu, process var būt atkarīgs no tā, vai katrā lietotnē pareizi tiek izpildīts kontrolsaraksts.

Microsoft vienotā pierakstīšanās organizācijām piedāvā vēl vienu iespēju. Savienojot Odoo ar Microsoft Entra ID, lietotāji var autentificēties, izmantojot savu Microsoft kontu, un uzņēmums var piemērot savas jau izveidotās Microsoft identitātes kontroles Odoo pierakstīšanās procesam.

Jūsu Microsoft identitātes pamats, iespējams, jau pastāv

Ja jūsu organizācija izmanto Microsoft 365, tai parasti jau ir Microsoft Entra darbaspēka tenants. Microsoft skaidro, ka darbaspēka tenants tiek izveidots darbiniekiem, iekšējām lietotnēm un organizācijas resursiem, kad uzņēmums reģistrējas Microsoft mākoņpakalpojumam, piemēram, Microsoft 365. Tas padara Entra par dabisku identitātes nodrošinātāju, ko apsvērt Odoo gadījumā, nevis ieviest vēl vienu atsevišķu kontu sistēmu. Skatiet Microsoft skaidrojumu par darbaspēka un ārējo tenantu konfigurācijām.

Odoo arī atzīst šo lietošanas gadījumu. Oficiālā Odoo 19 Microsoft Azure pierakstīšanās dokumentācija apraksta, kā Odoo lietotāji var pierakstīties ar Microsoft kontiem. Tajā arī skaidri norādīts, ka konfigurācija ir nepieciešama abās integrācijas pusēs.

Lielākais ieguvums ir tas, ka Microsoft kļūst par vietu, kur organizācija var piemērot autentifikācijas politiku pirms Odoo sesijas sākuma.

Pievienojiet spēcīgāku autentifikāciju Odoo pierakstīšanās ceļam

Microsoft Entra daudzfaktoru autentifikācija var prasīt divus vai vairāk pārbaudes veidus. Šie faktori var ietvert kaut ko, ko lietotājs zina, kaut ko, kas viņam pieder, vai kaut ko, kas viņš ir. Microsoft apraksta, kā šis izaicinājums tiek apstrādāts kā daļa no Entra pierakstīšanās procesa, savā MFA pārskatā.

Kad Odoo deleģē pierakstīšanos Entra, organizācija var pieprasīt apstiprinātu MFA metodi. Tāpat var virzīt atsevišķus lietotājus uz pretpikšķerēšanas metodēm, piemēram, piekļuves atslēgām, FIDO2 drošības atslēgām, Windows Hello for Business vai sertifikātu bāzētu autentifikāciju. Microsoft šīs metodes iesaka savā autentifikācijas vadlīnijā.

Šī atšķirība ir svarīga. Parasta MFA parasti ir drošāka nekā piekļuve tikai ar paroli, taču ne visas MFA metodes ir pretpikšķerēšanas aizsargātas. NIST norāda, ka paroles nav pretpikšķerēšanas aizsargātas un ka manuāli ievadīti vienreizējie kodi arī nav pretpikšķerēšanas aizsargāti, jo uzbrucējs tos var pārsūtīt tālāk. NIST WebAuthn, ko izmanto FIDO2 autentifikatori, norāda kā piemēru pretpikšķerēšanas aizsardzībai, izmantojot domēna saistīšanu. Sīkāka informācija ir pieejama NIST SP 800-63B-4.

SSO integrācija uzņēmumam sniedz iespēju izmantot šīs Entra iespējas Odoo. Taču uzņēmumam joprojām ir jāiespējo un jāpiemēro atbilstošās politikas.

Pieņemiet piekļuves lēmumus ar lielāku kontekstu

Microsoft Entra Conditional Access var izvērtēt tādus signālus kā lietotājs, grupa, lietotne, atrašanās vieta, ierīces statuss un pierakstīšanās risks. Pēc tam tas var bloķēt piekļuvi vai pieprasīt kontroles mehānismus, tostarp MFA, noteiktu autentifikācijas stiprumu vai atbilstošu ierīci. Microsoft sauc Conditional Access par savu Zero Trust politiku dzinēju un dokumentē pieejamos signālus un lēmumus Conditional Access pārskatā.

Odoo izvietošanā tas var atbalstīt tādas politikas kā:

  • MFA pieprasīšana Odoo administratoriem un finanšu lietotājiem.
  • Pretpikšķerēšanas autentifikācijas stipruma pieprasīšana priviliģētām lomām.
  • Odoo pierakstīšanās bloķēšana no vietām, kuras uzņēmums neapkalpo.
  • Atbilstošas vai pārvaldītas ierīces pieprasīšana sensitīvai iekšējai piekļuvei.
  • Striktākas politikas piemērošana ārējiem vai augstāka riska pierakstīšanās gadījumiem.

Šie ir piemēri, nevis universāli iestatījumi. Politika, kas piemērota iekšējai finanšu komandai, var nebūt piemērota klientu portālam. Pirms kontroles izvēles izlasiet kā Conditional Access stiprina Odoo pierakstīšanos.

Conditional Access ir arī licencēšanas prasības. Conditional Access nepieciešams Microsoft Entra ID P1, bet uz risku balstītām politikām nepieciešams P2. Microsoft 365 Business Premium ietver Conditional Access iespējas. Licencēšana un aktuālā funkciju pieejamība jāpārbauda, salīdzinot ar Microsoft oficiālo dokumentāciju.

Tuviniet identitāti un Odoo piekļuvi

Autentifikācija atbild uz jautājumu, kas ir lietotājs. Odoo autorizācija joprojām nosaka, ko šis lietotājs var darīt.

Labi izstrādāta integrācija var savienot apstiprinātu Microsoft identitāti ar esošu Odoo kontu, izveidot apstiprinātu kontu pirmajā pierakstīšanās reizē un kartēt atlasītās Entra grupas vai lietotņu lomas uz Odoo piekļuves grupām. Tas var samazināt dubultu administrēšanu un atvieglot piekļuves lēmumu pārskatīšanu.

Ir svarīgi saglabāt robežu starp identitāti un autorizāciju. Kāda lietotāja noņemšana no Entra grupas saskaņā ar integrācijas dokumentēto sinhronizācijas uzvedību var ietekmēt Odoo kartējumu, taču tas ne vienmēr nekavējoties pārtrauc esošo Odoo sesiju. Ja piekļuve tiek sinhronizēta pie pierakstīšanās, izmaiņas stājas spēkā, kad lietotājs pierakstās atkārtoti, ja vien to neietekmē cits sesijas kontroles mehānisms.

Uzmanība vajadzīga arī e-pasta adreses atbilstībai. Microsoft brīdina, ka e-pasta adreses un lietotāja galvenie vārdi var mainīties vai tikt izmantoti atkārtoti. Tā ID token claims vadlīnija ilgstošai identitātei iesaka nemainīgus identifikatorus, piemēram, sub vai oid, ar tenanta kontekstu, ja tas ir nepieciešams. E-pasts var būt noderīgs kontrolētā sākotnējā sasaistē, taču tam nevajadzētu būt pastāvīgajai identitātes atslēgai.

Padziļinātākam piekļuves dizainam lasiet kā centralizēt Odoo piekļuvi ar Entra grupām un lietotņu lomām.

Ko Microsoft SSO neaizstāj

Microsoft SSO neaizstāj Odoo atjauninājumus, minimālo privilēģiju lomas, ierakstu noteikumus, drošu hostingu, dublējumkopijas, uzraudzību, sesiju kontroli vai incidentu reaģēšanu. Oficiālā Odoo dokumentācija arī brīdina Odoo.com mitinātās datubāzes neizmantot tās dokumentēto OAuth plūsmu datubāzes īpašniekam vai administratoram, jo tas var ietekmēt portāla pārvaldību. Pirms ieviešanas apstipriniet īpašnieku un avārijas administrēšanu.

Drošāks veids, kā ieviest Microsoft pierakstīšanos

Sāciet ar nelielu testu grupu. Pārbaudiet Microsoft atklāšanas metadatus un parakstīšanas atslēgas, apstipriniet atpakaļsaistes URL, testējiet kontu saskaņošanu un pārbaudiet jaunu un nepilnvarotu lietotāju rezultātus. Saglabājiet avārijas administratīvo ceļu, līdz plūsma ir pārbaudīta no sākuma līdz beigām.

Pēc tam dokumentējiet politikas, kas attiecas uz Odoo, nepieciešamās Entra licences, to, kā grupu vai lomu izmaiņas nonāk Odoo, un kā atbalsts reaģēs, ja Microsoft pierakstīšanās nebūs pieejama. Ja klientiem un partneriem ir nepieciešama piekļuve, apsveriet atsevišķu klientu identitātes risinājumu, nevis uzskatiet viņus par darbiniekiem. Mūsu ceļvedis par Microsoft Entra External ID for Odoo customers and partners izskaidro šo atšķirību.

Ieviesiet vadītu Microsoft SSO Odoo 19

Mūsu Microsoft Entra SSO for Odoo module nodrošina vadītu savienojumu Odoo 19, tostarp darbaspēkam un ārējām auditorijām, kontrolētu pirmo pierakstīšanos, grupu un lietotņu lomu kartēšanu, pierakstīšanās testēšanu un tikai Microsoft interaktīvu pieteikšanos pēc validācijas. Tas izmanto OpenID Connect authorization code flow with PKCE.

Modulis nenosaka jūsu drošības politiku. Jūsu organizācija joprojām ir atbildīga par Entra konfigurāciju, Odoo piekļuves dizainu un ieviešanu.