Odoo często przechowuje informacje, które mają znaczenie dla całej organizacji: dane klientów, aktywność sprzedażową, faktury, dane pracowników, projekty, zapasy oraz dokumenty operacyjne. Dostęp do tych informacji zasługuje na taką samą uwagę jak dostęp do poczty, plików i innych kluczowych systemów biznesowych.

Mimo to Odoo może stać się wyspą tożsamości. Pracownicy mogą mieć jedno hasło do Microsoft 365 i inne do Odoo. Administratorzy mogą potrzebować zarządzać dostępem w różnych miejscach. Gdy ktoś zmienia rolę albo odchodzi z firmy, proces może zależeć od poprawnego wykonania checklisty w każdej aplikacji.

Microsoft single sign-on daje organizacjom kolejną opcję. Łącząc Odoo z Microsoft Entra ID, użytkownicy mogą uwierzytelniać się przez swoje konto Microsoft, a firma może stosować ustanowione kontrole tożsamości Microsoft do procesu logowania w Odoo.

Twoja baza tożsamości Microsoft może już istnieć

Jeśli Twoja organizacja korzysta z Microsoft 365, zazwyczaj ma już dzierżawę Microsoft Entra workforce. Microsoft wyjaśnia, że dzierżawa workforce jest tworzona dla pracowników, aplikacji wewnętrznych i zasobów organizacyjnych, gdy firma rejestruje się do usługi chmurowej Microsoft, takiej jak Microsoft 365. To sprawia, że Entra jest naturalnym dostawcą tożsamości do rozważenia dla Odoo, zamiast wprowadzania kolejnego samodzielnego systemu kont. Zobacz wyjaśnienie Microsoft dotyczące konfiguracji dzierżaw workforce i external.

Odoo również rozpoznaje ten przypadek użycia. Oficjalna dokumentacja logowania Odoo 19 za pomocą Microsoft Azure opisuje, jak użytkownicy Odoo mogą logować się przy użyciu kont Microsoft. Wyjaśnia też, że konfiguracja jest wymagana po obu stronach integracji.

Największą korzyścią jest to, że Microsoft staje się punktem, w którym organizacja może zastosować politykę uwierzytelniania, zanim rozpocznie się sesja Odoo.

Dodaj silniejsze uwierzytelnianie do ścieżki logowania Odoo

Wieloskładnikowe uwierzytelnianie Microsoft Entra może wymagać dwóch lub więcej form weryfikacji. Czynniki te mogą obejmować coś, co użytkownik wie, coś, co posiada, albo coś, czym jest. Microsoft opisuje, jak to wyzwanie jest obsługiwane jako część procesu logowania Entra w swoim omówieniu MFA.

Gdy Odoo deleguje logowanie do Entra, organizacja może wymagać zatwierdzonej metody MFA. Może też kierować wybranych użytkowników w stronę metod odpornych na phishing, takich jak passkeys, klucze bezpieczeństwa FIDO2, Windows Hello for Business lub uwierzytelnianie oparte na certyfikatach. Microsoft zaleca te metody w swoich wskazówkach dotyczących uwierzytelniania.

To rozróżnienie ma znaczenie. Tradycyjne MFA jest zazwyczaj silniejsze niż dostęp oparty wyłącznie na haśle, ale nie każda metoda MFA jest odporna na phishing. NIST stwierdza, że hasła nie są odporne na phishing, a ręcznie wpisywane jednorazowe kody również nie są odporne na phishing, ponieważ atakujący może je przekazać dalej. NIST wskazuje WebAuthn, używany przez uwierzytelnianie FIDO2, jako przykład odporności na phishing dzięki powiązaniu z domeną. Szczegóły znajdują się w NIST SP 800-63B-4.

Integracja SSO daje firmie możliwość wykorzystania tych funkcji Entra dla Odoo. Firma nadal musi włączyć i egzekwować odpowiednie zasady.

Podejmuj decyzje o dostępie z większym kontekstem

Microsoft Entra Conditional Access może oceniać sygnały takie jak użytkownik, grupa, aplikacja, lokalizacja, stan urządzenia i ryzyko logowania. Następnie może blokować dostęp albo wymagać kontroli, w tym MFA, określonej siły uwierzytelniania lub zgodnego urządzenia. Microsoft nazywa Conditional Access swoim silnikiem polityk Zero Trust i dokumentuje dostępne sygnały oraz decyzje w przeglądzie Conditional Access.

W przypadku wdrożenia Odoo może to wspierać polityki takie jak:

  • Wymaganie MFA dla administratorów Odoo i użytkowników finansowych.
  • Wymaganie siły uwierzytelniania odpornej na phishing dla ról uprzywilejowanych.
  • Blokowanie logowania do Odoo z lokalizacji, których firma nie obsługuje.
  • Wymaganie zgodnego lub zarządzanego urządzenia dla wrażliwego dostępu wewnętrznego.
  • Stosowanie bardziej rygorystycznej polityki wobec logowań zewnętrznych lub obarczonych większym ryzykiem.

To są przykłady, a nie uniwersalne ustawienia. Polityka odpowiednia dla wewnętrznego zespołu finansowego może nie nadawać się do portalu klienta. Przeczytaj jak Conditional Access wzmacnia logowanie do Odoo przed wyborem kontroli.

Conditional Access ma też wymagania licencyjne. Microsoft Entra ID P1 jest wymagany dla Conditional Access, a zasady oparte na ryzyku wymagają P2. Microsoft 365 Business Premium obejmuje możliwości Conditional Access. Licencjonowanie i aktualna dostępność funkcji należy sprawdzić w oficjalnej dokumentacji Microsoft.

Zbliż tożsamość i dostęp do Odoo

Uwierzytelnianie odpowiada na pytanie, kim jest użytkownik. Autoryzacja Odoo nadal decyduje, co ten użytkownik może zrobić.

Dobrze zaprojektowana integracja może dopasować zatwierdzoną tożsamość Microsoft do istniejącego konta Odoo, utworzyć zatwierdzone konto przy pierwszym logowaniu i przypisać wybrane grupy Entra lub role aplikacji do grup dostępu Odoo. Może to ograniczyć dublowanie administracji i ułatwić przegląd decyzji o dostępie.

Ważne jest zachowanie granicy między tożsamością a autoryzacją. Usunięcie kogoś z grupy Entra powinno wpłynąć na mapowanie Odoo zgodnie z udokumentowanym zachowaniem synchronizacji integracji, ale nie musi natychmiast kończyć istniejącej sesji Odoo. Jeśli dostęp jest synchronizowany przy logowaniu, zmiana zaczyna obowiązywać przy kolejnym logowaniu użytkownika, chyba że zadziała inna kontrola sesji.

Dopasowywanie adresu e-mail również wymaga ostrożności. Microsoft ostrzega, że adresy e-mail i nazwy użytkownika mogą się zmieniać lub być ponownie używane. Jego wskazówki dotyczące claimów tokena ID zalecają trwałe identyfikatory, takie jak sub lub oid, z kontekstem dzierżawy tam, gdzie jest to wymagane, dla trwałej tożsamości. E-mail może być przydatny podczas kontrolowanego pierwszego powiązania, ale nie powinien być trwałym kluczem tożsamości.

Aby uzyskać głębszy projekt dostępu, przeczytaj centralizację dostępu do Odoo za pomocą grup Entra i ról aplikacji.

Czego Microsoft SSO nie zastępuje

Microsoft SSO nie zastępuje aktualizacji Odoo, zasad najmniejszych uprawnień, reguł rekordów, bezpiecznego hostingu, kopii zapasowych, monitorowania, kontroli sesji ani reakcji na incydenty. Oficjalna dokumentacja Odoo ostrzega też bazy danych hostowane na Odoo.com przed używaniem opisanego przepływu OAuth dla właściciela bazy danych lub administratora, ponieważ może to wpłynąć na zarządzanie portalem. Przed wdrożeniem potwierdź właściciela i administrację awaryjną.

Bezpieczniejszy sposób wprowadzenia logowania Microsoft

Zacznij od małej grupy testowej. Zweryfikuj metadane wykrywania Microsoft i klucze podpisu, potwierdź adres URL wywołania zwrotnego, przetestuj dopasowywanie kont oraz sprawdź wyniki dla nowych i nieautoryzowanych użytkowników. Zachowaj awaryjną ścieżkę administracyjną, dopóki przepływ nie zostanie przetestowany end to end.

Następnie udokumentuj zasady mające zastosowanie do Odoo, wymagane licencje Entra, sposób, w jaki zmiany grup lub ról trafiają do Odoo, oraz to, jak wsparcie zareaguje, jeśli logowanie Microsoft będzie niedostępne. Jeśli klienci i partnerzy potrzebują dostępu, rozważ osobny projekt tożsamości klienta zamiast traktować ich jak pracowników. Nasz przewodnikMicrosoft Entra External ID for Odoo customers and partners wyjaśnia to rozróżnienie.

Wprowadź prowadzone logowanie jednokrotne Microsoft do Odoo 19

Nasz Microsoft Entra SSO for Odoo module zapewnia prowadzone połączenie dla Odoo 19, obejmujące pracowników i odbiorców zewnętrznych, kontrolowane pierwsze logowanie, mapowanie grup i ról aplikacji, testowanie logowania oraz interaktywne logowanie wyłącznie przez Microsoft po walidacji. Wykorzystuje przepływ autoryzacyjny OpenID Connect code flow z PKCE.

Moduł nie wybiera Twojej polityki bezpieczeństwa. Twoja organizacja pozostaje odpowiedzialna za konfigurację Entra, projekt dostępu do Odoo i wdrożenie.