Odoo portali daju kupcima i partnerima pristup relevantnim dokumentima, transakcijama i uslugama. To otvara pitanje dizajna identiteta: da li eksterni korisnici treba da dele direktorijum zaposlenih i model pristupa?
Ponekad je poslovni gost nalog u workforce tenant-u odgovarajući. U većem obimu, ili kada su potrebni brendirana prijava kupaca i samostalna registracija, Microsoft Entra External ID pruža namenski model upravljanja identitetom i pristupom za kupce.
Povezivanje tog modela sa Odoo može da podrži jasniju granicu između internih korisnika i portal korisnika. Ta granica i dalje zahteva eksplicitno odobrenje, kreiranje naloga i Odoo pravila autorizacije.
Workforce i external tenant-i su namenjeni različitim publikama
Microsoft definiše workforce tenant kao okruženje za zaposlene, interne poslovne aplikacije i organizacione resurse. On takođe može da sadrži pozvane poslovne partnere i goste. External tenant je posebna konfiguracija za aplikacije namenjene potrošačima i poslovnim kupcima. Microsoft opisuje razliku u svojim uputstvima za konfiguraciju tenant-a.
External tenant sadrži sopstveni direktorijum kupaca i registracije aplikacija. External ID dodaje samostalnu registraciju, prijavu, resetovanje lozinke, upravljanje nalogom i federaciju sa provajderima identiteta. Pregled External ID objašnjava ovaj namenski model.
Ova separacija može pomoći organizaciji da ne tretira kupca kao zaposlenog samo zato što oboje treba da pristupe Odoo usluzi.
Izaberite publiku pre konfiguracije prijave
Postoje najmanje tri različite Odoo publike koje treba razmotriti:
Zaposleni i interni korisnici
Ovi korisnici obično pripadaju workforce tenant-u organizacije. Ako im se odobri pristup Odoo-u, uglavnom su im potrebni interni Odoo korisnički nalozi sa pažljivo mapiranim grupama pristupa.
Ljudi iz odobrenih partnerskih organizacija
Neke kompanije žele korisnike iz definisanog spiska customer ili partner Entra tenant-a. Multi-tenant workforce veza sa tačnim allow-listom tenant-a može biti odgovarajuća kada je svaka organizacija poznata i pristup je ugovorno odobren.
Validacija tenant-a je ključna. Poređenje samo na osnovu email domena nije dovoljno jer su domeni i email adrese promenljivi. Potvrdite token-ov tenant i nepromenljive subject ili object identifikatore prema dizajnu veze.
Kupci i eksterni korisnici
Za aplikacije okrenute ka kupcima, External ID tenant može da obezbedi poseban direktorijum i iskustvo prijave. Odoo nalozi kreirani za ovu publiku obično treba da budu portal korisnici, a ne interni korisnici.
Ovi modeli treba da budu konfigurisan kao posebne veze kada se njihova pravila odobravanja i Odoo naloga razlikuju. Jedna široka veza je teža za razumevanje i lakša za pogrešnu konfiguraciju.
External ID podržava tok prijave kupaca
External ID user flow-ovi definišu metode autentifikacije kupaca i informacije koje se prikupljaju tokom registracije. Flow je povezan sa registrovanim aplikacijama kako bi se aktivirali registracija i prijava. Microsoft ovo dokumentuje u dodavanju aplikacije u External ID user flow.
External ID može da podrži lokalne naloge i federaciju sa provajderima identiteta, uključujući Microsoft Entra ID i prilagođene OpenID Connect provajdere. Ugrađeni i prilagođeni atributi mogu se prikupljati tokom registracije, kao što je opisano u Microsoftovim smernicama za atribute kupaca.
Prikupljajte samo informacije koje Odoo zaista treba, i dokumentujte svrhu, period čuvanja i privatni tretman svakog atributa.
Podrazumevana dozvola pomaže da se očuva separacija
Microsoft navodi da korisnici external tenant-a počinju sa ograničenim podrazumevanim dozvolama. Oni uglavnom mogu da pristupaju aplikacijama i upravljaju sopstvenim profilom, ali ne dobijaju široka prava administracije direktorijuma. Pogledajte podrazumevane dozvole u external tenant-ima.
Ta granica direktorijuma ne konfiguriše automatski Odoo portal dozvole. Odoo i dalje kontroliše koje zapise portal korisnik može da vidi kroz sopstvena prava pristupa i record rules. Testirajte portal iskustvo sa reprezentativnim zapisima kupaca i sa više od jedne kompanije ili naloga kako biste osigurali da su podaci ispravno izolovani.
Nemojte promovisati novo kreiranog eksternog korisnika u internog Odoo korisnika osim ako ne postoji zaseban, odobren poslovni proces.
Koristite moderan, validiran OpenID Connect tok
Microsoft podržava OAuth 2.0 authorization code flow sa Proof Key for Code Exchange i OpenID Connect za server-based web aplikacije. Njegova dokumentacija za authorization code flow opisuje tu podržanu kombinaciju.
OIDC proširuje OAuth 2.0 za autentifikaciju. Microsoft objavljuje discovery metadata, detalje endpoint-a i javne signing ključeve. Takođe preporučuje validaciju vraćenog token-a i proveru nonce vrednosti radi smanjenja rizika od replay napada. Pogledajte OpenID Connect na Microsoft identity platform.
Bezbedna integracija treba da validira očekivani issuer, audience, signature, tenant context i nonce. PKCE ne zamenjuje validaciju tokena, preciznu konfiguraciju callback-a, TLS ili zaštitu client secret-a.
Osnovna prijava može da zatraži standardne OIDC scope-ove kao što su openid, profile i email. Microsoft napominje da su ovi scope-ovi hostovani na Microsoft Graph-u i preporučuje da se traže samo dozvole koje su aplikaciji potrebne. Pogledajte scope-ove Microsoft identity platform. Precizna tvrdnja o proizvodu je zato "bez visokoprivilegovanih Microsoft Graph API dozvola za standardnu prijavu," a ne opšta tvrdnja da Graph nije uključen.
Odlučite kako eksterni korisnici dolaze do Odoo-a
Pre nego što omogućite prvu prijavu, definišite:
- Da li je samoregistracija otvorena ili je potrebno odobrenje.
- Koji tenant-i ili provajderi identiteta su dopušteni.
- Da li postojeći Odoo portal nalog može da se poveže.
- Koji nepromenljivi Microsoft identifikator se čuva nakon povezivanja.
- Kojoj Odoo kompaniji i partneru korisnik pripada.
- Koje portalne grupe i pravila zapisa se primenjuju.
- Šta se dešava kada se pristup opozove.
- Kako se aktivna Odoo sesija opoziva.
Automatsko kreiranje naloga može smanjiti administraciju, ali treba da se desi tek nakon što identitet ispuni pravila za prijem u vezi. Uspešna Microsoft autentifikacija dokazuje kontrolu nad prihvaćenim identitetom. Ona sama po sebi ne dokazuje da ta osoba treba da vidi određene Odoo zapise klijenta.
Planirajte korisničku podršku i oporavak
Spoljni korisnici možda nemaju internu službu za pomoć. Objavite putanju za podršku i navedite ko upravlja identitetom. Testirajte scenarije za reset lozinke, oporavak, uklanjanje iz tenant-a i promenu e-pošte. Zadržite dijagnostičke događaje korisnim, ali anonimizovanim.
Ako vam je trenutna potreba pristup zaposlenih, pročitajte zašto treba da zaštitite svoju Odoo instancu uz Microsoft SSO. Za interne dozvole, pogledajte centralizovanje Odoo pristupa uz Entra grupe i aplikacione uloge.
Povežite spoljne publike sa Odoo 19
Naš Microsoft Entra SSO za Odoo modul podržava odvojene veze za zaposlene, odobrene organizacije i Microsoft Entra External ID korisničke publike. Veze za External ID podrazumevano kreiraju portal korisnike, dok veze za radnu snagu kreiraju interne korisnike. Vođeno podešavanje validira informacije za otkrivanje i potpisne ključeve, a zatim zahteva interaktivni test pre nego što se omogući Microsoft prijavljivanje.
Modul ne odlučuje ko treba da bude primljen ni koje bi korisničke zapise trebalo da vidi. To i dalje ostaju poslovne i Odoo odluke o pristupu. Razmotrite modul ako vam je potreban kontrolisan most između Microsoft identiteta klijenta i Odoo 19 portala, sa obradom naloga specifičnom za publiku, umesto jedne nediferencirane putanje prijave.