Konfiguracja OpenID Connect i Okta dla SSO Sophos Central
Sophos Central może korzystać z dostawcy OpenID Connect do Single Sign-on inicjowanego przez SP. Logowanie rozpoczyna się w Sophos Central, 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 Central, przetestowany administrator awaryjny oraz dostawca OIDC, który akceptuje Authorization Requests oczekiwane przez Sophos. Wszystkie objęte zmianą konta Central muszą być przypisane do domeny i dokładnie jednego dostawcy tożsamości.
Central wymaga czterech wartości dostawcy:
| Pole | Znaczenie |
|---|---|
| Client ID | publiczny identyfikator aplikacji OIDC utworzonej dla Sophos Central |
| Issuer | dokładny adres URL wystawcy, którego wartość odpowiada claimowi iss w ID Token |
| Authz endpoint | punkt końcowy HTTPS dla Authorization Request |
| JWKS URL | punkt 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:
- Wybrać OIDC – OpenID Connect, a następnie Single-Page Application.
- Nadać jednoznaczną nazwę, na przykład
Sophos Central SSO. - W sekcji Grant type wyłączyć Core Grant Authorization Code.
- W sekcji Advanced > Other grants włączyć Implicit (hybrid).
- Jako Sign-in redirect URI wprowadzić
https://federation.sophos.com/login/callback. - Usunąć istniejące Sign-out redirect URIs.
- 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ę.
- 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 Central
- Otworzyć Global Settings > Access Control > Sign-in and Identity > Federated identity providers.
- Wybrać Add identity provider i wprowadzić nazwę oraz opis.
- Wybrać Type: OpenID Connect i odpowiedniego dostawcę, na przykład Okta.
- Dokładnie wprowadzić Client ID, Issuer, Authz Endpoint i JWKS URL.
- Wybrać zweryfikowaną domenę. Można wskazać kilka domen, ale użytkownik pozostaje przypisany dokładnie do jednej z nich.
- Opcję IdP enforced MFA wybrać tylko wtedy, gdy dostawca gwarantuje MFA dla wszystkich objętych nim tożsamości. W przeciwnym razie użyć No IdP enforced MFA.
- 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 Central 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 Sophos sign-in najpierw wybiera się tryb równoległy z hasłem Sophos i poświadczeniami federacyjnymi. Następnie 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 Central 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ść
issw ID Token musi dokładnie odpowiadać polu Issuer w Central. - 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 Central 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 Central.
Sign-in Rules, dostęp break-glass, odzyskiwanie MFA i zmianę trybu tenanta opisano w artykule Zabezpieczenie logowania Sophos Central za pomocą MFA, passkeys i IdP.