Logowanie jednokrotne odpowiada na pytanie uwierzytelniania: czy Microsoft zweryfikował tego użytkownika zgodnie z polityką organizacji? Nie odpowiada ono na każde pytanie autoryzacyjne wewnątrz Odoo.

Uwierzytelniony użytkownik może potrzebować dostępu do sprzedaży, ale nie do księgowości, do projektów, ale nie do płac, albo do portalu klienta, ale nie do interfejsu wewnętrznego. Te decyzje pozostają w gestii Odoo. Grupy Microsoft Entra i role aplikacji mogą dostarczać zaufanych danych wejściowych, aby podejmować je bardziej spójnie.

Grupy i role aplikacji pełnią różne funkcje

Grupy Microsoft Entra należą do dzierżawy. Mogą reprezentować działy, funkcje zawodowe, projekty lub granice bezpieczeństwa. Role aplikacji należą do konkretnej rejestracji aplikacji i opisują role istotne dla tej aplikacji.

Dokumentacja Microsoftu ról aplikacji wyjaśnia, że role aplikacji mogą być przypisywane użytkownikom lub grupom. Gdy przypisany użytkownik się loguje, Entra może uwzględnić przyznane role w claimie roles. Microsoft podaje też, że role aplikacji i grupy nie wykluczają się wzajemnie.

Daje to projektowi dostępu do Odoo dwa główne wzorce:

  • Mapuj stabilne Object ID grup zabezpieczeń Entra bezpośrednio do wybranych grup Odoo.
  • Zdefiniuj role aplikacji ukierunkowane na Odoo w aplikacji Entra, przypisz użytkowników lub grupy do tych ról i mapuj wynikowe wartości ról do grup Odoo.

Bezpośrednie mapowanie dobrze działa z nadzorowanymi grupami zabezpieczeń. Role aplikacji mogą zapewnić czytelniejszą granicę aplikacji, ponieważ ich znaczenie jest powiązane z rejestracją aplikacji, a nie zależy od nazw specyficznych dla dzierżawy.

Zacznij od rzeczywistego modelu dostępu Odoo

Nie zaczynaj od kopiowania każdej grupy Microsoftu do Odoo. Zacznij od uprawnień Odoo, których naprawdę potrzebuje firma.

Wypisz grupy Odoo, które przyznają istotne możliwości. Dla każdej z nich udokumentuj:

  • Biznesowy cel tego dostępu.
  • Osobę odpowiedzialną za jego zatwierdzenie.
  • Grupę Entra lub rolę aplikacji, która reprezentuje zatwierdzenie.
  • Jak szybko zmiana powinna dotrzeć do Odoo i co dzieje się z aktywną sesją po usunięciu.

Stosuj zasadę najmniejszych uprawnień. Szeroka grupa działowa może być wygodna, ale może przyznawać więcej dostępu do Odoo, niż potrzebuje każdy jej członek. Mniejsza, specyficzna dla Odoo grupa zabezpieczeń lub rola aplikacji jest często łatwiejsza do audytu.

Traktuj powiązanie tożsamości jako kontrolę bezpieczeństwa

Wiele systemów początkowo dopasowuje istniejące konto na podstawie adresu e-mail. Jest to wygodne, zwłaszcza gdy Odoo i Microsoft używają już tego samego firmowego adresu e-mail. Nie jest to jednak trwały klucz tożsamości.

Microsoft ostrzega w swoim odwołaniu do claims tokena ID , że adresy e-mail, numery telefonów i nazwy głównych użytkowników mogą się zmieniać i mogą być ponownie używane. Microsoft zaleca niezmienne claims, takie jak sub lub oid, oraz tid, gdy wymagany jest kontekst dzierżawy, dla niezawodnej identyfikacji.

Bezpieczniejszy wzorzec to:

  1. Dopuszczaj tylko oczekiwaną dzierżawę i zatwierdzoną grupę odbiorców.
  2. Używaj e-maila do kontrolowanego pierwszego dopasowania, tam gdzie to właściwe.
  3. Odrzucaj niejednoznaczne lub zduplikowane dopasowania.
  4. Zapisz niezmienny identyfikator Microsoft i identyfikator dzierżawy po powiązaniu.
  5. Używaj tych niezmiennych wartości przy kolejnych logowaniach.

W przypadku dostępu wielodzierżawowego kontekst dzierżawy jest kluczowy. Ta sama osoba może mieć różne identyfikatory obiektu w różnych dzierżawach, a dostęp z jednej dzierżawy nie powinien po cichu dziedziczyć uprawnień powiązanych z inną.

Zrozum przypadek nadmiaru claimów grup

Claims grup są wygodne, ale nie są nieograniczone. Microsoft dokumentuje limit 200 Object ID grup w JWT. Gdy członkostwo użytkownika przekracza ten limit, Entra pomija zwykłą listę grup i zwraca wskaźnik nadmiaru, który kieruje aplikację do zapytania Microsoft Graph. Zobacz wskazówki dotyczące nadmiaru grup.

Ma to znaczenie, jeśli integracja reklamuje mapowanie grup bez podwyższonych uprawnień Microsoft Graph API. Użytkownik z rozbudowanym członkostwem w grupach może nie otrzymać oczekiwanego zestawu claimów grup.

Zanim oprzesz się na bezpośrednim mapowaniu grup, potwierdź, jak obsługiwany jest nadmiar. Opcje obejmują mniejsze grupy specyficzne dla aplikacji, role aplikacji, filtrowanie claimów albo wyszukiwanie oparte na Graph z udzieleniem najmniejszych uprawnień.

Synchronizacja przy logowaniu nie jest aprowizacją w czasie rzeczywistym

Moduł SSO może porównać bieżące claims Entra z skonfigurowanymi mapowaniami Odoo, gdy użytkownik się loguje. Jest to przydatne, ponieważ dostęp może zostać dopasowany podczas zwykłego zdarzenia uwierzytelniania.

Nie jest to to samo co ciągła aprowizacja. Jeśli pracownik zostanie usunięty z grupy Entra, gdy sesja Odoo jest aktywna, ta sesja może trwać do wylogowania, wygaśnięcia albo zastosowania innej kontroli unieważnienia. Jeśli były pracownik nigdy nie zaloguje się ponownie, proces synchronizacji przy logowaniu sam z siebie nie archiwizuje konta Odoo.

Microsoft Entra ID Governance oferuje Lifecycle Workflows dla procesów joiner, mover i leaver, w tym wyłączanie kont i usuwanie przypisań dostępu. Zobacz dokumentację Microsoftu dotyczącą Lifecycle Workflows. Te możliwości wymagają licencji Microsoft Entra ID Governance lub Microsoft Entra Suite.

Automatyzacja cyklu życia może poprawić stan tożsamości źródłowej, ale nadal nie aktualizuje Odoo, chyba że integracja obsługuje tę zmianę. Procedura offboardingu powinna wyraźnie obejmować unieważnienie sesji Odoo i stan konta.

Zbuduj audytowalny model mapowania

Utrzymuj liczbę mapowań na poziomie, który jest zrozumiały. Dla każdej grupy lub roli używaj stabilnego identyfikatora i opisu czytelnego dla człowieka. Zapisz, dlaczego powiązany dostęp do Odoo istnieje, kto go zatwierdził i kiedy był ostatnio przeglądany.

Przetestuj co najmniej następujące przypadki:

  • Istniejący użytkownik z jednym oczekiwanym mapowaniem.
  • Użytkownik bez zatwierdzonego mapowania lub z niedozwoloną dzierżawą.
  • Nowy użytkownik dopuszczony przy pierwszym logowaniu.
  • Użytkownik usunięty z mapowanej grupy lub mający wiele członkostw w grupach.
  • Zmieniony użytkownik, którego niezmienna tożsamość nie uległa zmianie.
  • Wyłączone konto Microsoft z istniejącą sesją Odoo.

Zdarzenia logowania powinny pomagać administratorom diagnozować wyniki claimów i mapowania bez ujawniania tokenów, poświadczeń ani sekretów. Dzienniki powinny identyfikować połączenie i wynik, ale wrażliwe wartości powinny być redagowane.

Połącz mapowanie z polityką uwierzytelniania

Kontrole mapowania grup i ról sterują autoryzacją Odoo. Microsoft Entra Conditional Access kontroluje, czy Microsoft dokończy uwierzytelnianie w bieżących warunkach. Te dwie warstwy uzupełniają się nawzajem.

Na przykład rola aplikacji Entra może mapować się do grupy finansowej Odoo, podczas gdy Conditional Access wymaga odpornej na phishing siły uwierzytelniania dla użytkowników przypisanych do tej roli. Przeczytaj jak Microsoft Entra Conditional Access wzmacnia logowanie do Odoo po stronie polityki uwierzytelniania.

W przypadku klientów i partnerów nie używaj automatycznie ponownie mapowań pracowników. Osobna grupa odbiorców i projekt ukierunkowany na portal mogą być bezpieczniejsze. Zobacz Microsoft Entra External ID dla klientów i partnerów Odoo.

Mapuj zatwierdzony dostęp Microsoft do Odoo 19

Nasza Microsoft Entra SSO for Odoo module obsługuje mapowanie skonfigurowanych identyfikatorów Object ID grup zabezpieczeń Entra lub ról aplikacji do wybranych grup dostępu Odoo. Może synchronizować te mapowania podczas logowania, łączyć kontrolowane istniejące konto i tworzyć zatwierdzonych użytkowników pracowniczych lub portalowych zgodnie z typem połączenia.

Moduł nie zastępuje nadzoru nad dostępem, unieważniania sesji ani udokumentowanej strategii obejścia limitu. Przed włączeniem mapowań sprawdź skalę grup, wymagania dotyczące powiązania tożsamości oraz model uprawnień Odoo. Jeśli te podstawy są jasne, moduł zapewnia prowadzone sposoby ich połączenia.