Przejdz do tresci
Avanet

Konfiguracja OpenID Connect i Okta dla SSO Sophos Fusion

Sophos Fusion (dawniej Sophos Central) może korzystać z dostawcy OpenID Connect do Single Sign-on inicjowanego przez SP. Logowanie rozpoczyna się w Sophos Fusion, a następnie użytkownik zostaje przekierowany do dostawcy tożsamości. Sam link do dashboardu uruchamiany z IdP nie jest więc prawidłowym testem działania.

Wymagania

Wymagane są konto Super Admin, domena zweryfikowana w Fusion, przetestowany administrator awaryjny oraz dostawca OIDC, który akceptuje Authorization Requests oczekiwane przez Sophos. Wszystkie objęte zmianą konta Fusion muszą być przypisane do domeny i dokładnie jednego dostawcy tożsamości.

Domenę konfiguruje się przed dostawcą:

  1. Otworzyć Global Settings > Access Control > Sign-in and Identity > Sophos Sign-in > Verify domains.
  2. W sekcji Federated domains wybrać Add domain i wprowadzić domenę organizacji. example.com jest tylko przykładem i należy ją zastąpić.
  3. Za pomocą Copy pobrać wyświetlony rekord TXT, opublikować go w publicznym DNS i poczekać na propagację. Według Sophos może to potrwać do 24 godzin.
  4. W Fusion wybrać dla domeny Verify domain ownership, a następnie Verify. Status musi pokazywać domenę wraz z datą weryfikacji.

Weryfikacja jest ważna przez rok i można ją odnowić w tym okresie. Jej wygaśnięcie należy uwzględnić w planie operacyjnym; działająca dziś federacja nie usuwa potrzeby późniejszej ponownej weryfikacji.

Fusion wymaga czterech wartości dostawcy:

PoleZnaczenie
Client IDpubliczny identyfikator aplikacji OIDC utworzonej dla Sophos Fusion
Issuerdokładny adres URL wystawcy, którego wartość odpowiada claimowi iss w ID Token
Authz endpointpunkt końcowy HTTPS dla Authorization Request
JWKS URLpunkt końcowy HTTPS zawierający publiczne klucze podpisu dostawcy

Callback URL ma dokładnie postać https://federation.sophos.com/login/callback. Sophos żąda przy tym zakresu openid profile email, wartości response_type=id_token oraz response_mode=form_post. Dostawca musi zwracać ID Token; w tym przepływie Sophos nie żąda Authorization Code.

Konfiguracja aplikacji Okta

W Okta Admin Console tworzy się aplikację w sekcji Applications > Create App Integration:

  1. Wybrać OIDC – OpenID Connect, a następnie Single-Page Application.
  2. Nadać jednoznaczną nazwę, na przykład Sophos Fusion SSO.
  3. W sekcji Grant type wyłączyć Core Grant Authorization Code.
  4. W sekcji Advanced > Other grants włączyć Implicit (hybrid).
  5. Jako Sign-in redirect URI wprowadzić https://federation.sophos.com/login/callback.
  6. Usunąć istniejące Sign-out redirect URIs.
  7. Na początku ograniczyć przypisanie do zdefiniowanej grupy pilotażowej. Sophos pokazuje jako prosty przykład udostępnienie aplikacji wszystkim użytkownikom organizacji, ale w bezpiecznym wdrożeniu grupa pilotażowa daje większą kontrolę.
  8. Zapisać konfigurację i zanotować Client ID.

Issuer udostępnia używana domena autoryzacyjna Okta. W przypadku Custom Domain może to wyglądać na przykład tak: https://login.example.com. Zwykle wynikają z tego następujące wartości:

Issuer:         https://login.example.com
Authz endpoint: https://login.example.com/oauth2/v1/authorize
JWKS URL:       https://login.example.com/oauth2/v1/keys

Wartości nie kopiuje się z przykładu, lecz sprawdza względem konfiguracji Discovery lub konfiguracji dostawcy we własnym tenancie Okta. Issuer korzystający z innego Authorization Server może zawierać odmienne ścieżki.

Tworzenie dostawcy w Sophos Fusion

  1. Otworzyć Global Settings > Access Control > Sign-in and Identity > Federated identity providers.
  2. Wybrać Add identity provider i wprowadzić nazwę oraz opis.
  3. Wybrać Type: Open ID Connect i odpowiedniego dostawcę, na przykład Okta.
  4. Dokładnie wprowadzić Client ID, Issuer, Authz Endpoint i JWKS URL.
  5. Wybrać zweryfikowaną domenę. Można wskazać kilka domen, ale użytkownik pozostaje przypisany dokładnie do jednej z nich.
  6. Opcję IdP enforced MFA wybrać tylko wtedy, gdy dostawca gwarantuje MFA dla wszystkich objętych nim tożsamości. Przy ustawieniu No IdP enforced MFA Fusion wymusza własną kontrolę MFA po udanym uwierzytelnieniu przez IdP.
  7. Zapisać, ponownie otworzyć dostawcę i po pełnym skonfigurowaniu aktywować go za pomocą Turn on.

W przypadku Google Workspace Sophos wskazuje OIDC jako możliwego dostawcę, ale w instrukcji Fusion nie podaje porównywalnego pełnego zestawu pól. Wartości przejmuje się więc z rzeczywiście używanej konfiguracji OIDC Google lub Cloud Identity i sprawdza w pilotażu. Ścieżek Okta nie przenosi się do Google.

Tryb logowania i pilotaż

W sekcji Global Settings > Access Control > Sign-in and Identity > Sophos sign-in najpierw wybiera się Sophos Central Admin or Federated credentials. Po zapisaniu administrator wykonujący zmianę sprawdza, czy Fusion automatycznie dodał go do Custom Sign-in Rule z logowaniem Sophos. Reguła ta stanowi dodatkową drogę awaryjną, ale nie zastępuje oddzielnie przetestowanego drugiego konta Super Admin.

Test pozytywny rozpoczyna się pod adresem https://fusion.sophos.com w prywatnej sesji przeglądarki. Po wprowadzeniu pilotażowego adresu e-mail przeglądarka musi przekierować do Okta, zażądać tam przewidzianej MFA, a następnie otworzyć dashboard Sophos Fusion z oczekiwaną rolą. Potem testuje się co najmniej następujące przypadki:

  • prawidłowy użytkownik pilotażowy z IdP MFA,
  • użytkownik bez przypisania aplikacji,
  • nieprawidłowa lub niezweryfikowana domena,
  • wygasła sesja IdP,
  • wylogowanie i ponowne logowanie inicjowane przez SP,
  • drugi administrator Super Admin korzystający z dostępu awaryjnego.

Dopiero po udanym pilotażu rozważa się tryb Federated credentials only. Przypisanie aplikacji IdP wszystkim użytkownikom nie zastępuje sprawdzenia, czy każde konto Fusion jest przypisane do właściwej domeny i dostawcy.

Rozwiązywanie problemów

  • Invalid redirect lub pętla logowania: sprawdzić callback, typ aplikacji i przepływ Implicit ID Token.
  • Unknown issuer: wartość iss w ID Token musi dokładnie odpowiadać polu Issuer w Fusion.
  • Nie można zweryfikować podpisu: sprawdzić JWKS URL, dostępność przez HTTPS oraz aktualnie opublikowany klucz.
  • Nie znaleziono użytkownika: porównać claim email, adres e-mail w Fusion i przypisanie domeny.
  • Nie można włączyć dostawcy: pola wymagane, domena lub format URL są niekompletne bądź nieprawidłowe.
  • Brak MFA lub MFA pojawia się dwukrotnie: wspólnie sprawdzić politykę IdP oraz ustawienie IdP enforced MFA w Fusion.

Bezpieczne wyłączenie lub wycofanie zmian

Przed pracami konserwacyjnymi u dostawcy OIDC należy w sekcji Sophos sign-in ponownie wybrać Sophos Central Admin or Federated credentials. Następnie dwóch administratorów Super Admin testuje dostęp Sophos w prywatnych sesjach przeglądarki. Przy pełnym powrocie do Sophos Central Admin email and password użytkownicy bez działającego hasła Sophos ustawiają nowe za pomocą Reset Password.

Dostawcę w Fusion wyłącza się lub odbiera przypisania aplikacji IdP dopiero po tych testach. Domenę, wartości dostawcy, aplikację IdP i Custom Sign-in Rule zachowuje się do czasu potwierdzenia logowania, ról i Self Service Portal przez ścieżkę awaryjną. Jeśli ścieżka zawiedzie, dostawca OIDC pozostaje aktywny, a poprzednie ustawienie logowania zostaje przywrócone.

Sign-in Rules, dostęp break-glass, odzyskiwanie MFA i zmianę trybu tenanta opisano w artykule Zabezpieczenie logowania Sophos Fusion za pomocą MFA, passkeys i IdP.

Często zadawane pytania

Czy Sophos Fusion obsługuje Authorization Code Flow?

Aktualna instrukcja Sophos opisuje dla tego przepływu OIDC żądanie Implicit z response_type=id_token i bez żądania Authorization Code. Aplikacja dostawcy musi dokładnie odpowiadać temu udokumentowanemu zachowaniu.