Kertakirjautuminen vastaa todennuskysymykseen: onko Microsoft vahvistanut tämän käyttäjän organisaation käytännön mukaisesti? Se ei vastaa kaikkiin Odoo:n sisäisiin valtuutuskysymyksiin.
Todennettu käyttäjä voi tarvita pääsyn myyntiin mutta ei kirjanpitoon, projekteihin mutta ei palkkahallintoon, tai asiakasportaaliin mutta ei sisäiseen käyttöliittymään. Nämä päätökset ovat edelleen Odoo:n vastuulla. Microsoft Entra -ryhmät ja sovellusroolit voivat tarjota luotettavia syötteitä, joiden avulla päätökset tehdään yhdenmukaisemmin.
Ryhmät ja sovellusroolit palvelevat eri tarkoituksia
Microsoft Entra -ryhmät kuuluvat tenanttiin. Ne voivat edustaa osastoja, työtehtäviä, projekteja tai tietoturvarajoja. Sovellusroolit kuuluvat tiettyyn sovellusrekisteröintiin ja kuvaavat rooleja, jotka ovat merkityksellisiä kyseiselle sovellukselle.
Microsoftin sovellusroolien dokumentaatio selittää, että sovellusrooleja voidaan määrittää käyttäjille tai ryhmille. Kun määritetty käyttäjä kirjautuu sisään, Entra voi sisällyttää myönnetyt roolit roles-vaateeseen. Microsoft toteaa myös, että sovellusroolit ja ryhmät eivät sulje toisiaan pois.
Tämä antaa Odoo-käyttöä varten kaksi päämallia:
- Määritä vakaat Entra-tietoturvaryhmän Object ID:t suoraan valittuihin Odoo-ryhmiin.
- Määritä Entra-sovellukseen Odoo-keskeiset sovellusroolit, anna käyttäjille tai ryhmille nämä roolit ja mapita syntyvät rooliarvot Odoo-ryhmiin.
Suora mappaus toimii hyvin hallittujen tietoturvaryhmien kanssa. Sovellusroolit voivat tarjota selkeämmän sovellusrajan, koska niiden tarkoitus kulkee sovellusrekisteröinnin mukana eikä riipu tenanttikohtaisista nimistä.
Lähde liikkeelle Odoo:n todellisesta käyttömallista
Älä aloita kopioimalla jokaista Microsoft-ryhmää Odoo:hon. Aloita Odoo-oikeuksista, joita liiketoiminta todella tarvitsee.
Listaa Odoo-ryhmät, jotka antavat olennaisia toimintoja. Dokumentoi jokaisesta:
- Käytön liiketoiminnallinen tarkoitus.
- Henkilö, joka vastaa sen hyväksymisestä.
- Entra-ryhmä tai sovellusrooli, joka edustaa hyväksyntää.
- Kuinka nopeasti muutos pitäisi näkyä Odoo:ssa ja mitä tapahtuu aktiiviselle istunnolle poiston jälkeen.
Käytä vähimpien oikeuksien periaatetta. Laaja osastoryhmä voi olla kätevä, mutta se voi antaa enemmän Odoo-käyttöä kuin jokainen jäsen tarvitsee. Pienempi Odoo-kohtainen tietoturvaryhmä tai sovellusrooli on usein helpompi auditoida.
Käsittele identiteetin sitomista tietoturvavalvontana
Monet järjestelmät yhdistävät aluksi olemassa olevan tilin sähköpostiosoitteen perusteella. Tämä on kätevää, etenkin kun Odoo ja Microsoft käyttävät jo samaa yrityssähköpostia. Se ei kuitenkaan ole pysyvä tunniste.
Microsoft varoittaa ID token claims reference -ohjeessaan, että sähköpostiosoitteet, puhelinnumerot ja user principal name -arvot voivat muuttua ja niitä voidaan käyttää uudelleen. Microsoft suosittelee luotettavaan tunnistamiseen muuttumattomia vaateita, kuten sub tai oid, ja tarvittaessa tid:tä tenant-kontekstia varten.
Turvallisempi malli on:
- Salli vain odotettu tenantti ja hyväksytty audience.
- Käytä sähköpostia hallittuun ensimmäiseen vastaavuuteen, kun se on tarkoituksenmukaista.
- Hylkää epäselvät tai päällekkäiset vastineet.
- Tallenna muuttumaton Microsoft-identiteetti ja tenant-tunnisteet linkityksen jälkeen.
- Käytä näitä muuttumattomia arvoja tulevissa kirjautumisissa.
Moni-tenanttisessa käytössä tenant-konteksti on välttämätön. Samalla henkilöllä voi olla eri Object ID:t eri tenanteissa, eikä yhden tenantin käyttöoikeuksien pidä siirtyä huomaamatta toisen tenantin perusteella.
Ymmärrä group-claimin ylärajatilanne
Group claims on kätevä, mutta niitä ei ole rajattomasti. Microsoft dokumentoi JWT:ssä 200 group Object ID:n rajan. Kun käyttäjän jäsenyydet ylittävät rajan, Entra jättää normaalin ryhmälistan pois ja palauttaa overage-ilmaisimen, joka ohjaa sovelluksen kysymään Microsoft Graphia. Katso groups overage guidance.
Tämä on tärkeää, jos integraatio lupaa ryhmämappausta ilman Microsoft Graph API:n laajennettuja oikeuksia. Käyttäjä, jolla on paljon ryhmäjäsenyyksiä, ei välttämättä saa odotettua group claim -joukkoa.
Ennen kuin tukeudut suoraan ryhmämappaukseen, varmista miten overage käsitellään. Vaihtoehtoja ovat pienemmät sovelluskohtaiset ryhmät, sovellusroolit, claim-suodatus tai Graph-pohjainen haku vähimmillä oikeuksilla annetulla suostumuksella.
Synkronointi kirjautumisen yhteydessä ei ole reaaliaikaista provisiointia
SSO-moduuli voi verrata käyttäjän kirjautuessa nykyisiä Entra-vaateita määritettyihin Odoo-mappauksiin. Se on hyödyllistä, koska käyttöoikeudet voidaan kohdistaa normaalin todennustapahtuman aikana.
Se ei ole sama asia kuin jatkuva provisiointi. Jos työntekijä poistetaan Entra-ryhmästä samalla kun Odoo-istunto on aktiivinen, istunto voi jatkua, kunnes käyttäjä kirjautuu ulos, istunto vanhenee tai jokin muu peruutusmekanismi tulee voimaan. Jos entinen työntekijä ei koskaan kirjaudu enää uudelleen, kirjautumisen aikainen synkronointi ei itsessään arkistoi Odoo-tiliä.
Microsoft Entra ID Governance tarjoaa Lifecycle Workflows -toiminnallisuudet joiner-, mover- ja leaver-prosesseihin, mukaan lukien tilien poistaminen käytöstä ja käyttöoikeusmääritysten poistaminen. Katso Microsoftin Lifecycle Workflows guidance -ohje. Nämä ominaisuudet edellyttävät Microsoft Entra ID Governance- tai Microsoft Entra Suite -lisensointia.
Elinkaaren automaatio voi parantaa lähdeidentiteetin tilaa, mutta se ei silti päivitä Odoo:a, ellei integraatio lue muutosta. Offboarding-prosessin pitäisi kattaa nimenomaisesti Odoo-istunnon peruutus ja tilin tila.
Rakenna auditoitava mappausmalli
Pidä mappausten määrä ymmärrettävänä. Käytä jokaiselle ryhmälle tai roolille vakaata tunnistetta ja ihmisen luettavaa kuvausta. Kirjaa, miksi siihen liittyvä Odoo-käyttö on olemassa, kuka sen hyväksyi ja milloin se tarkistettiin viimeksi.
Testaa ainakin nämä tapaukset:
- Olemassa oleva käyttäjä yhdellä odotetulla mappauksella.
- Käyttäjä, jolla ei ole hyväksyttyä mappausta tai jolla on kielletty tenantti.
- Uusi käyttäjä, joka hyväksytään ensimmäiseen kirjautumiseen.
- Käyttäjä, joka on poistettu mapatusta ryhmästä tai jolla on paljon ryhmäjäsenyyksiä.
- Nimetty käyttäjä, jonka muuttumaton identiteetti ei ole muuttunut.
- Poistettu Microsoft-tili, jolla on olemassa oleva Odoo-istunto.
Kirjautumistapahtumien tulisi auttaa ylläpitäjiä diagnosoimaan claim- ja mapping-tuloksia paljastamatta tokeneita, tunnistetietoja tai salaisuuksia. Lokkien tulisi yksilöidä yhteys ja tulos, mutta arkaluonteiset arvot tulisi peittää.
Yhdistä mapping todennuskäytäntöön
Ryhmä- ja roolimapping ohjaa Odoo-valtuutusta. Microsoft Entra Conditional Access ohjaa sitä, suorittaako Microsoft todennuksen loppuun nykyisissä olosuhteissa. Nämä kaksi kerrosta täydentävät toisiaan.
Esimerkiksi Entra-sovelluksen rooli voi mapata Odoo-taloutta varten tarkoitettuun ryhmään, kun taas Conditional Access edellyttää kyseiselle roolille määritetyiltä käyttäjiltä phishing-resistant-todennusvahvuutta. Lue miten Microsoft Entra Conditional Access vahvistaa Odoo-kirjautumista todennuskäytäntöä koskevasta näkökulmasta.
Asiakkaille ja kumppaneille älä käytä työntekijöiden mappingeja automaattisesti uudelleen. Erillinen yleisöön ja portaaliin keskittyvä suunnittelu voi olla turvallisempi. Katso Microsoft Entra External ID for Odoo customers and partners.
Mappaus hyväksytyille Microsoft-käyttöoikeuksille Odoo 19:ssä
Meidän Microsoft Entra SSO for Odoo module tukee määritettyjen Entra-tietoturvaryhmien Object ID:iden tai sovellusroolien mappaamista valittuihin Odoo-käyttöryhmiin. Se voi synkronoida nämä mappaukset kirjautumisen yhteydessä, liittää hallitun olemassa olevan tilin ja luoda hyväksyttyjä työntekijä- tai portaalikäyttäjiä yhteystyypin mukaan.
Moduuli ei korvaa käyttöoikeuksien hallintaa, istunnon mitätöintiä tai dokumentoitua ylivuotostrategiaa. Tarkista ryhmien koko, identiteetin sitomista koskevat vaatimukset ja Odoo-käyttöoikeusmalli ennen mappausten käyttöönottoa. Jos nämä perustat ovat kunnossa, moduuli tarjoaa ohjatun tavan yhdistää ne.