Portale Odoo zapewniają klientom i partnerom dostęp do odpowiednich dokumentów, transakcji i usług. To rodzi pytanie dotyczące projektowania tożsamości: czy użytkownicy zewnętrzni powinni korzystać ze wspólnego katalogu pracowników i modelu dostępu?

Czasami właściwe jest konto gościa biznesowego w tenantcie pracowniczym. W większej skali, albo gdy wymagane są markowane logowanie klienta i rejestracja samoobsługowa, Microsoft Entra External ID zapewnia dedykowany model zarządzania tożsamością i dostępem klientów.

Połączenie tego modelu z Odoo może wspierać wyraźniejszą granicę między użytkownikami wewnętrznymi a użytkownikami portalu. Taka granica nadal wymaga jawnego dopuszczenia, utworzenia konta i reguł autoryzacji Odoo.

Tenants pracownicze i zewnętrzne są przeznaczone dla różnych odbiorców

Microsoft definiuje tenant pracowniczy jako środowisko dla pracowników, wewnętrznych aplikacji biznesowych i zasobów organizacji. Może on także zawierać zaproszonych partnerów biznesowych i gości. Tenant zewnętrzny to osobna konfiguracja dla aplikacji oferowanych konsumentom i klientom biznesowym. Microsoft opisuje tę różnicę w swoich wskazówkach dotyczących konfiguracji tenantów.

Tenant zewnętrzny zawiera własny katalog klientów i rejestracje aplikacji. External ID dodaje rejestrację samoobsługową, logowanie, reset hasła, zarządzanie kontem oraz federację z dostawcami tożsamości. Omówienie External ID wyjaśnia ten dedykowany model.

Taki podział może pomóc organizacji uniknąć traktowania klienta jak pracownika tylko dlatego, że oboje potrzebują dostępu do usługi Odoo.

Wybierz odbiorców przed skonfigurowaniem logowania

Należy rozważyć co najmniej trzy odrębne grupy odbiorców Odoo:

Pracownicy i użytkownicy wewnętrzni

Użytkownicy ci zazwyczaj należą do tenanta pracowniczego organizacji. Jeśli otrzymają dostęp do Odoo, zwykle potrzebują wewnętrznych kont użytkowników Odoo z odpowiednio przypisanymi grupami dostępu.

Osoby z zatwierdzonych organizacji partnerskich

Niektóre firmy chcą dopuścić użytkowników z określonej listy tenantów Entra klientów lub partnerów. Wielotenantowe połączenie pracownicze z dokładną listą dozwolonych tenantów może być odpowiednie, gdy każda organizacja jest znana, a dostęp jest zatwierdzony umownie.

Walidacja tenanta ma kluczowe znaczenie. Samo dopasowanie domeny e-mail nie wystarczy, ponieważ domeny i adresy e-mail mogą ulegać zmianie. Zweryfikuj tenant tokena oraz niezmienne identyfikatory subject lub object zgodnie z projektem połączenia.

Klienci i użytkownicy zewnętrzni

W przypadku aplikacji skierowanych do klientów tenant External ID może zapewnić oddzielny katalog i doświadczenie logowania. Konta Odoo tworzone dla tej grupy powinny zazwyczaj być użytkownikami portalu, a nie użytkownikami wewnętrznymi.

Te modele należy konfigurować jako oddzielne połączenia, gdy różnią się zasady dopuszczenia i reguły kont Odoo. Jedno szerokie połączenie jest trudniejsze do zrozumienia i łatwiejsze do błędnej konfiguracji.

External ID obsługuje ścieżkę logowania klientów

Przepływy użytkownika External ID definiują metody uwierzytelniania klientów oraz informacje zbierane podczas rejestracji. Przepływ jest powiązany z zarejestrowanymi aplikacjami, aby aktywować rejestrację i logowanie. Microsoft dokumentuje to w dodawaniu aplikacji do przepływu użytkownika External ID.

External ID może obsługiwać konta lokalne i federację z dostawcami tożsamości, w tym Microsoft Entra ID oraz niestandardowymi dostawcami OpenID Connect. Wbudowane i niestandardowe atrybuty mogą być zbierane podczas rejestracji, zgodnie z opisem w wskazówkach Microsoft dotyczących atrybutów klientów.

Zbieraj tylko te informacje, których Odoo rzeczywiście potrzebuje, i dokumentuj cel, okres przechowywania oraz sposób traktowania prywatności każdego atrybutu.

Domyślne uprawnienia pomagają zachować separację

Microsoft podaje, że użytkownicy tenantów zewnętrznych zaczynają z ograniczonymi domyślnymi uprawnieniami. Zazwyczaj mogą oni uzyskiwać dostęp do aplikacji i zarządzać własnym profilem, ale nie otrzymują szerokich uprawnień administracyjnych katalogu. Zobacz domyślne uprawnienia w tenantach zewnętrznych.

Ta granica katalogu nie konfiguruje automatycznie uprawnień portalu Odoo. Odoo nadal kontroluje, które rekordy może zobaczyć użytkownik portalu, poprzez własne prawa dostępu i reguły rekordów. Przetestuj działanie portalu na reprezentatywnych rekordach klientów oraz z więcej niż jedną firmą lub kontem, aby upewnić się, że dane są prawidłowo odizolowane.

Nie awansuj nowo utworzonego użytkownika zewnętrznego do wewnętrznego użytkownika Odoo, chyba że istnieje odrębny, zatwierdzony proces biznesowy.

Użyj nowoczesnego, zweryfikowanego przepływu OpenID Connect

Microsoft obsługuje przepływ autoryzacji OAuth 2.0 z Proof Key for Code Exchange oraz OpenID Connect dla aplikacji webowych działających po stronie serwera. Jego dokumentacja przepływu autoryzacji code flow opisuje to obsługiwane połączenie.

OIDC rozszerza OAuth 2.0 o uwierzytelnianie. Microsoft publikuje metadane wykrywania, szczegóły punktów końcowych i publiczne klucze podpisujące. Zaleca także walidację zwróconego tokena i sprawdzenie nonce, aby zmniejszyć ryzyko odtworzenia. Zobacz OpenID Connect na platformie tożsamości Microsoft.

Bezpieczna integracja powinna weryfikować oczekiwany issuer, audience, podpis, kontekst tenanta oraz nonce. PKCE nie zastępuje walidacji tokena, dokładnej konfiguracji przekierowania, TLS ani ochrony tajemnicy klienta.

Podstawowe logowanie może żądać standardowych zakresów OIDC, takich jak openid, profile i email. Microsoft zauważa, że te zakresy są hostowane w Microsoft Graph i zaleca żądanie tylko tych uprawnień, których aplikacja potrzebuje. Zobacz zakresy platformy tożsamości Microsoft. Dokładne stwierdzenie dotyczące produktu brzmi więc: "brak uprawnień Microsoft Graph API o wysokich uprawnieniach dla standardowego logowania", a nie ogólne twierdzenie, że Graph nie jest w to zaangażowany.

Zdecyduj, jak użytkownicy zewnętrzni będą uzyskiwać dostęp do Odoo

Przed włączeniem pierwszego logowania zdefiniuj:

  • Czy samoobsługowa rejestracja jest otwarta, czy wymaga zatwierdzenia.
  • Które tenenty lub dostawcy tożsamości są dopuszczeni.
  • Czy istniejące konto portalu Odoo może zostać połączone.
  • Który niezmienny identyfikator Microsoft jest przechowywany po połączeniu.
  • Do której spółki i do którego rekordu partnera w Odoo należy użytkownik.
  • Które grupy portalu i reguły rekordów mają zastosowanie.
  • Co się dzieje, gdy dostęp zostaje odebrany.
  • Jak aktywna sesja Odoo jest unieważniana.

Automatyczne tworzenie kont może zmniejszyć nakład administracyjny, ale powinno następować dopiero wtedy, gdy tożsamość spełnia reguły dopuszczenia dla połączenia. Pomyślne uwierzytelnienie Microsoft potwierdza kontrolę nad zaakceptowaną tożsamością. Samo w sobie nie potwierdza jednak, że dana osoba powinna widzieć konkretne rekordy Odoo klienta.

Zaplanowanie obsługi klienta i odzyskiwania dostępu

Użytkownicy zewnętrzni mogą nie mieć wewnętrznego help desku. Opublikuj ścieżkę wsparcia i wskaż, kto zarządza tożsamością. Przetestuj reset hasła, odzyskiwanie konta, usunięcie tenant oraz scenariusze zmiany adresu e-mail. Zachowuj przydatność zdarzeń diagnostycznych, ale anonimizuj dane.

Jeśli Twoją pilną potrzebą jest dostęp pracowników, przeczytaj dlaczego warto chronić instancję Odoo za pomocą Microsoft SSO. W przypadku uprawnień wewnętrznych zobacz centralizację dostępu do Odoo za pomocą grup Entra i ról aplikacji.

Połącz odbiorców zewnętrznych z Odoo 19

Nasz moduł Microsoft Entra SSO dla Odoo obsługuje oddzielne połączenia dla pracowników, zatwierdzonych organizacji oraz odbiorców klientów Microsoft Entra External ID. Połączenia External ID domyślnie tworzą użytkowników portalu, natomiast połączenia dla pracowników tworzą użytkowników wewnętrznych. Prowadzona konfiguracja weryfikuje informacje o wykrywaniu i klucze podpisu, a następnie wymaga interaktywnego testu przed włączeniem logowania Microsoft.

Moduł nie decyduje o tym, kogo należy dopuścić ani jakie rekordy klientów powinni widzieć. To pozostaje decyzją biznesową i decyzją dotyczącą dostępu w Odoo. Zapoznaj się z modułem, jeśli potrzebujesz kontrolowanego połączenia między tożsamością klienta Microsoft a portalem Odoo 19, z obsługą kont dostosowaną do odbiorców zamiast jedną, niepodzieloną ścieżką logowania.