Konfigurera OpenID Connect och Okta för Sophos Central SSO

Sophos Central kan använda en OpenID Connect-provider för SP-initierad Single Sign-on. Inloggningen börjar i Sophos Central och vidarebefordras därifrån till Identity Provider. En Dashboard-länk som startas från IdP:n är därför inte i sig ett giltigt funktionstest.

Förutsättningar

Det krävs en Super Admin, en domän som verifierats i Central, en testad reservadministratör och en OIDC-provider som accepterar de Authorization Requests som Sophos förväntar sig. Alla berörda Central-konton måste vara kopplade till en domän och exakt en Identity Provider.

Central behöver fyra providervärden:

Fält	Betydelse
Client ID	offentlig identifierare för OIDC-applikationen som skapats för Sophos Central
Issuer	exakt utfärdar-URL vars värde överensstämmer med `iss`-claim i ID Token
Authz endpoint	HTTPS-endpoint för Authorization Request
JWKS URL	HTTPS-endpoint med providerns publika signeringsnycklar

Callback URL är exakt https://federation.sophos.com/login/callback. Sophos begär openid profile email, response_type=id_token och response_mode=form_post. Providern måste leverera en ID Token; Sophos begär ingen Authorization Code i detta flöde.

Konfigurera Okta-appen

I Okta Admin Console skapas en applikation under Applications > Create App Integration:

Välj OIDC – OpenID Connect och därefter Single-Page Application.
Ange ett unikt namn, exempelvis Sophos Central SSO.
Avmarkera Core Grant Authorization Code under Grant type.
Aktivera Implicit (hybrid) under Advanced > Other grants.
Ange https://federation.sophos.com/login/callback som Sign-in redirect URI.
Ta bort befintliga Sign-out redirect URIs.
Begränsa tilldelningen till en definierad pilotgrupp till att börja med. Sophos visar tilldelning till alla organisationsanvändare som ett enkelt exempel, men en pilotgrupp ger bättre kontroll vid en säker utrullning.
Spara och notera Client ID.

Issuer tillhandahålls av den Okta Authorization Domain som används. Med en Custom Domain kan den exempelvis se ut som https://login.example.com. Det ger normalt följande värden:

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

Värdena kopieras inte från ett exempel, utan kontrolleras mot Discovery- eller providerkonfigurationen i den egna Okta-tenanten. En Issuer med en annan Authorization Server kan innehålla andra sökvägar.

Skapa providern i Sophos Central

Öppna Global Settings > Access Control > Sign-in and Identity > Federated identity providers.
Välj Add identity provider och ange namn och beskrivning.
Välj Type: OpenID Connect och rätt leverantör, exempelvis Okta.
Ange Client ID, Issuer, Authz Endpoint och JWKS URL exakt.
Välj den verifierade domänen. Flera domäner är möjliga, men en användare förblir kopplad till exakt en domän.
Välj endast IdP enforced MFA om providern garanterar MFA för alla berörda identiteter. Använd annars No IdP enforced MFA.
Spara, öppna providern igen och aktivera den med Turn on när konfigurationen är fullständig.

Sophos anger OIDC som möjlig provider för Google Workspace, men tillhandahåller inte en motsvarande fullständig uppsättning fält i Central-anvisningen. Värdena hämtas därför från den Google- eller Cloud Identity-OIDC-konfiguration som faktiskt används och valideras i piloten. Okta-sökvägar överförs inte till Google.

Inloggningsläge och pilot

Under Sophos sign-in väljs först det parallella läget med Sophos-lösenord och federerade autentiseringsuppgifter. Därefter testas åtminstone följande fall:

giltig pilotanvändare med IdP-MFA,
användare utan apptilldelning,
felaktig eller ej verifierad domän,
utgången IdP-session,
utloggning och ny SP-initierad inloggning,
en andra Super Admin via reservvägen.

Federated credentials only övervägs först efter en lyckad pilot. Att tilldela IdP-appen till alla användare ersätter inte kontrollen av att varje Central-konto är kopplat till rätt domän och provider.

Felsökning

Invalid redirect eller inloggningsloop: Kontrollera callback, applikationstyp och Implicit-ID-Token-flöde.
Unknown issuer: iss i ID Token måste exakt motsvara Central-fältet Issuer.
Signaturen kan inte verifieras: Kontrollera JWKS URL, HTTPS-åtkomst och den nyckel som för närvarande publiceras.
Användaren hittas inte: Jämför email-claim, Central-e-postadress och domäntilldelning.
Providern kan inte aktiveras: Obligatoriska fält, domän eller URL-format är ofullständiga eller ogiltiga.
MFA saknas eller visas dubbelt: Kontrollera IdP-policyn och Central-valet IdP enforced MFA tillsammans.

Sign-in Rules, Break-Glass-åtkomst, MFA-Recovery och byte av tenantläge förklaras i Skydda Sophos Central-inloggning med MFA, passkeys och IdP.

Vanliga frågor

Stöder Sophos Central Authorization Code Flow?

Den aktuella Sophos-anvisningen beskriver för detta OIDC-flöde en Implicit Request med response_type=id_token och utan en begärd Authorization Code. Providerappen måste exakt motsvara detta dokumenterade beteende.

Kan länken i Okta Dashboard användas som test?

Nej. Sophos Central använder ett SP-initierat flöde. Testet börjar på Sophos inloggningssida så att domänrouting, request och callback faktiskt kontrolleras.