Odoo sisaldab sageli teavet, mis on oluline kogu organisatsioonile: kliendikirjed, müügitegevus, arved, töötajate andmed, projektid, laoseis ja operatiivdokumendid. Selle teabe juurdepääs väärib sama tähelepanu kui juurdepääs e-postile, failidele ja teistele põhitegevussüsteemidele.
Ometi võib Odoo muutuda identiteedisaariks. Töötajatel võib olla üks parool Microsoft 365 jaoks ja teine Odoo jaoks. Haldurid võivad pidada juurdepääsu eri kohtades. Kui keegi vahetab rolli või lahkub ettevõttest, võib protsess sõltuda sellest, kas kontrollnimekiri täidetakse õigesti igas rakenduses.
Microsofti ühekordne sisselogimine annab organisatsioonidele veel ühe võimaluse. Ühendades Odoo Microsoft Entra ID-ga, saavad kasutajad autentida oma Microsofti konto kaudu ja ettevõte saab rakendada oma olemasolevaid Microsofti identiteedikontrolle Odoo sisselogimisprotsessis.
Teie Microsofti identiteedibaas võib juba olemas olla
Kui teie organisatsioon kasutab Microsoft 365-t, on sellel tavaliselt juba Microsoft Entra tööjõu tenant. Microsoft selgitab, et tööjõu tenant luuakse töötajate, sisemiste rakenduste ja organisatsiooni ressursside jaoks siis, kui ettevõte registreerub Microsofti pilveteenuse, näiteks Microsoft 365, kasutajaks. See teeb Entrast loomuliku identiteedipakkuja, mida Odoo puhul kaaluda, selle asemel et võtta kasutusele veel üks eraldiseisev kontosüsteem. Vt Microsofti selgitust tööjõu ja välise tenant'i konfiguratsioonide kohta.
Odoo tunnistab ka seda kasutusjuhtu. Ametlik Odoo 19 Microsoft Azure sisselogimise dokumentatsioon kirjeldab, kuidas Odoo kasutajad saavad Microsofti kontodega sisse logida. Samuti teeb see selgeks, et integreerimine tuleb seadistada mõlemal poolel.
Suurem eelis on see, et Microsoftist saab koht, kus organisatsioon saab rakendada autentimispoliitikat enne Odoo seansi algust.
Lisage Odoo sisselogimisrajale tugevam autentimine
Microsoft Entra mitmikautentimine võib nõuda kahte või enamat kinnitamisviisi. Need tegurid võivad hõlmata midagi, mida kasutaja teab, midagi, mis tal on, või midagi, mis ta on. Microsoft kirjeldab, kuidas väljakutse käsitletakse Entra sisselogimisprotsessi osana, oma MFA ülevaates.
Kui Odoo delegeerib sisselogimise Entra'le, saab organisatsioon nõuda heakskiidetud MFA-meetodit. Samuti saab ta suunata valitud kasutajaid phishing-resistant meetodite juurde, nagu passkey'd, FIDO2 turvavõtmed, Windows Hello for Business või sertifikaadipõhine autentimine. Microsoft soovitab neid meetodeid oma autentimisjuhistes.
See eristus on oluline. Tavapärane MFA on üldiselt tugevam kui ainult parooliga juurdepääs, kuid mitte iga MFA-meetod ei ole phishing-resistant. NIST ütleb, et paroolid ei ole phishing-resistant ja et käsitsi sisestatud ühekordsed koodid ei ole phishing-resistant, sest ründaja saab neid vahendada. NIST nimetab WebAuthni, mida kasutatakse FIDO2 autentijates, näitena domeeniga sidumise kaudu toimivast phishing-resistant kaitsmest. Detailid on toodud NIST SP 800-63B-4 dokumendis.
SSO-integratsioon annab ettevõttele tee kasutada neid Entra võimalusi Odoo jaoks. Ettevõte peab siiski vajalikud poliitikad ise lubama ja jõustama.
Tehke juurdepääsuotsuseid suurema konteksti abil
Microsoft Entra Conditional Access saab hinnata signaale nagu kasutaja, rühm, rakendus, asukoht, seadme olek ja sisselogimisrisk. Seejärel saab see juurdepääsu blokeerida või nõuda kontrolle, sealhulgas MFA-d, kindlat autentimistugevust või nõuetele vastavat seadet. Microsoft nimetab Conditional Accessi oma Zero Trust poliitikamootoriks ja dokumenteerib saadaolevad signaalid ja otsused Conditional Accessi ülevaates.
Odoo juurutuse puhul võib see toetada selliseid poliitikaid nagu:
- MFA nõudmine Odoo administraatoritele ja finantstöötajatele.
- Phishing-resistant autentimistugevuse nõudmine privilegeeritud rollidele.
- Odoo sisselogimise blokeerimine asukohtadest, mida ettevõte ei teeninda.
- Nõuetele vastava või hallatava seadme nõudmine tundliku sisemise juurdepääsu jaoks.
- Tugevama poliitika rakendamine välistele või kõrgema riskiga sisselogimistele.
Need on näited, mitte universaalsed seaded. Poliitika, mis sobib sisemisele finantstiimile, võib olla kliendiportaali jaoks sobimatu. Enne kontrollide valimist lugege kuidas Conditional Access tugevdab Odoo sisselogimist.
Conditional Accessil on ka litsentsinõuded. Conditional Accessi jaoks on vaja Microsoft Entra ID P1-t, riskipõhised poliitikad nõuavad P2-t. Microsoft 365 Business Premium sisaldab Conditional Accessi võimalusi. Litsentsi ja praegust funktsionaalsust tuleks kontrollida Microsofti ametlikust dokumentatsioonist.
Tooge identiteet ja Odoo juurdepääs üksteisele lähemale
Autentimine vastab küsimusele, kes kasutaja on. Odoo autoriseerimine otsustab endiselt, mida see kasutaja teha saab.
Hästi kavandatud integreerimine saab sobitada heakskiidetud Microsofti identiteedi olemasoleva Odoo kontoga, luua heakskiidetud konto esimesel sisselogimisel ja siduda valitud Entra rühmad või rakenduse rollid Odoo juurdepääsurühmadega. See võib vähendada topelthaldust ja muuta juurdepääsuotsuste ülevaatamise lihtsamaks.
Oluline on säilitada identiteedi ja autoriseerimise vaheline piir. Kellegi eemaldamine Entra rühmast peaks mõjutama Odoo kaardistust vastavalt integreerimise dokumenteeritud sünkroonimiskäitumisele, kuid see ei katkesta tingimata olemasolevat Odoo seanssi kohe. Kui juurdepääs sünkroonitakse sisselogimisel, jõustub muudatus siis, kui kasutaja järgmine kord sisse logib, välja arvatud juhul, kui mõni muu seansikontroll sekkub.
E-posti sobitamine vajab samuti tähelepanu. Microsoft hoiatab, et e-posti aadressid ja kasutaja põhi-identifikaatorid võivad muutuda või neid võidakse uuesti kasutada. Selle ID token claimide juhend soovitab püsiva identiteedi jaoks muutumatuid identifikaatoreid, nagu sub või oid, vajaduse korral koos tenant'i kontekstiga. E-post võib olla kasulik kontrollitud esmasel sidumisel, kuid sellest ei tohiks saada püsivat identiteedivõtit.
Sügavamaks juurdepääsukujunduseks lugege Odoo juurdepääsu tsentraliseerimisest Entra rühmade ja rakenduserollidega.
Mida Microsoft SSO ei asenda
Microsoft SSO ei asenda Odoo uuendusi, vähimate privileegide rolle, kirje-reegleid, turvalist majutust, varukoopiaid, monitooringut, seansikontrolle ega intsidentidele reageerimist. Ametlik Odoo dokumentatsioon hoiatab ka Odoo.com hostitud andmebaase selle dokumenteeritud OAuth-voo kasutamise eest andmebaasi omaniku või administraatori jaoks, sest portaali haldamine võib olla mõjutatud. Kinnitage omaniku ja hädaolukorra haldus enne juurutamist.
Turvalisem viis Microsofti sisselogimise kasutuselevõtuks
Alusta väikese testgrupiga. Kinnita Microsofti avastusmetaandmed ja allkirjastamisvõtmed, kontrolli tagasihelistamise URL-i, testi konto sobitamist ning uute ja volitamata kasutajate tulemusi. Hoia hädaolukorra haldusmeetod alles seni, kuni voog on algusest lõpuni testitud.
Seejärel dokumenteeri poliitikad, mis kehtivad Odoo puhul, vajalikud Entra litsentsid, kuidas grupi- või rollimuudatused jõuavad Odooru, ning kuidas tugi reageerib, kui Microsofti sisselogimine pole saadaval. Kui klientidel ja partneritel on vaja juurdepääsu, kaalu eraldi kliendi identiteedilahendust, mitte ära käsitle neid töötajatena. Meie juhend Microsoft Entra External ID Odoo klientidele ja partneritele selgitab seda erinevust.
Too juhitud Microsoft SSO Odoo 19-sse
Meie Microsoft Entra SSO for Odoo moodul pakub juhitud ühendust Odoo 19 jaoks, sealhulgas töötajate ja väliste sihtrühmade jaoks, kontrollitud esmast sisselogimist, rühma- ja rakenduserollide kaardistamist, sisselogimise testimist ning pärast kinnitamist ainult Microsofti interaktiivset sisselogimist. See kasutab OpenID Connecti autoriseerimiskoodi voogu koos PKCE-ga.
Moodul ei vali sinu turvapoliitikat. Sinu organisatsioon vastutab jätkuvalt Entra seadistuse, Odoo juurdepääsulahenduse ja juurutamise eest.