Configurare OpenID Connect e Okta per Sophos Central SSO

Sophos Central può utilizzare un provider OpenID Connect per il Single Sign-on avviato dal service provider. L’accesso inizia in Sophos Central, che reindirizza poi all’Identity Provider. Un collegamento alla dashboard avviato dall’IdP non costituisce quindi un test funzionale valido.

Prerequisiti

Servono un Super Admin, un dominio verificato in Central, un amministratore di emergenza testato e un provider OIDC che accetti le Authorization Request previste da Sophos. Ogni account Central interessato deve essere assegnato a un dominio e a un solo Identity Provider.

Il dominio va configurato prima del provider:

Aprire Global Settings > Access Control > Sign-in and Identity > Sophos Sign-in > Verify domains.
In Federated domains, selezionare Add domain e inserire il dominio aziendale. example.com è solo un esempio e deve essere sostituito.
Usare Copy per acquisire il record TXT visualizzato, pubblicarlo nel DNS pubblico e attendere la propagazione. Sophos indica che può richiedere fino a 24 ore.
In Central, selezionare Verify domain ownership per il dominio e poi Verify. Lo stato deve mostrare il dominio con la data di verifica.

La verifica vale un anno e può essere rinnovata durante tale periodo. La scadenza va inserita nella pianificazione operativa: una federazione funzionante oggi non elimina la successiva riverifica.

Central richiede quattro valori del provider:

Campo	Significato
Client ID	identificativo pubblico dell’applicazione OIDC creata per Sophos Central
Issuer	URL esatto dell’emittente, il cui valore coincide con il claim `iss` dell’ID Token
Authz endpoint	endpoint HTTPS per l’Authorization Request
JWKS URL	endpoint HTTPS contenente le chiavi pubbliche di firma del provider

La Callback URL è esattamente https://federation.sophos.com/login/callback. Sophos richiede openid profile email, response_type=id_token e response_mode=form_post. Il provider deve fornire un ID Token; in questo flusso Sophos non richiede un Authorization Code.

Configurare l’app Okta

Nella Okta Admin Console si crea un’applicazione in Applications > Create App Integration:

Selezionare OIDC – OpenID Connect e poi Single-Page Application.
Assegnare un nome univoco, per esempio Sophos Central SSO.
In Grant type deselezionare il Core Grant Authorization Code.
In Advanced > Other grants attivare Implicit (hybrid).
Inserire https://federation.sophos.com/login/callback come Sign-in redirect URI.
Rimuovere gli eventuali Sign-out redirect URI.
Limitare inizialmente l’assegnazione a un gruppo pilota definito. Sophos mostra come esempio semplice l’accesso per tutti gli utenti dell’organizzazione; per un rollout sicuro un gruppo pilota è più controllabile.
Salvare e annotare il Client ID.

L’Issuer proviene dall’Okta Authorization Domain utilizzato. Con un Custom Domain può essere, per esempio, https://login.example.com. Di norma ne derivano:

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

I valori non vanno copiati da un esempio, ma verificati nella configurazione Discovery o del provider del proprio tenant Okta. Un Issuer che usa un altro Authorization Server può avere percorsi differenti.

Creare il provider in Sophos Central

Aprire Global Settings > Access Control > Sign-in and Identity > Federated identity providers.
Selezionare Add identity provider e inserire nome e descrizione.
Scegliere Type: Open ID Connect e il Vendor appropriato, per esempio Okta.
Inserire esattamente Client ID, Issuer, Authz Endpoint e JWKS URL.
Selezionare il dominio verificato. Sono possibili più domini, ma ogni utente resta assegnato esattamente a uno di essi.
Selezionare IdP enforced MFA solo se il provider garantisce MFA per tutte le identità interessate. Con No IdP enforced MFA, Central applica una propria verifica MFA dopo l’autenticazione IdP riuscita.
Salvare, riaprire il provider e, dopo aver completato la configurazione, attivarlo con Turn on.

Sophos indica OIDC come possibile provider anche per Google Workspace, ma la guida Central non fornisce un set di campi completo paragonabile. I valori vanno quindi ricavati dalla configurazione OIDC di Google o Cloud Identity effettivamente utilizzata e convalidati nel pilota. I percorsi Okta non vanno trasferiti a Google.

Modalità di accesso e pilota

In Global Settings > Access Control > Sign-in and Identity > Sophos sign-in si seleziona prima Sophos Central Admin or Federated credentials. Dopo il salvataggio, l’amministratore che ha effettuato la modifica verifica che Central lo abbia aggiunto automaticamente a una Custom Sign-in Rule con accesso Sophos. Questa regola è un percorso di emergenza aggiuntivo, non sostituisce un secondo Super Admin testato separatamente.

Il test positivo inizia dalla pagina di accesso Sophos in una sessione privata del browser. Dopo l’inserimento dell’indirizzo e-mail pilota, il browser deve reindirizzare a Okta, richiedere lì la MFA prevista e quindi aprire la dashboard Central con il ruolo atteso. Si testano poi almeno questi casi:

utente pilota valido con MFA dell’IdP,
utente senza assegnazione all’app,
dominio errato o non verificato,
sessione IdP scaduta,
logout e nuovo accesso avviato dal service provider,
secondo Super Admin tramite il percorso di emergenza.

Solo dopo un pilota riuscito si valuta Federated credentials only. Assegnare l’app IdP a tutti gli utenti non sostituisce la verifica che ogni account Central sia associato al dominio e al provider corretti.

Troubleshooting

Invalid redirect o ciclo di login: controllare callback, tipo di applicazione e flusso Implicit con ID Token.
Unknown issuer: il valore iss nell’ID Token deve coincidere esattamente con il campo Central Issuer.
Impossibile verificare la firma: controllare JWKS URL, raggiungibilità HTTPS e chiave attualmente pubblicata.
Utente non trovato: confrontare claim email, indirizzo Central e assegnazione del dominio.
Impossibile attivare il provider: campi obbligatori, dominio o formato URL sono incompleti o non validi.
MFA assente o duplicata: controllare insieme la policy IdP e la scelta Central IdP enforced MFA.

Disattivazione o rollback sicuri

Prima della manutenzione del provider OIDC, in Sophos sign-in si torna a Sophos Central Admin or Federated credentials. Due Super Admin verificano quindi il proprio accesso Sophos in sessioni private del browser. Per tornare completamente a Sophos Central Admin email and password, gli utenti senza una password Sophos utilizzabile ne impostano una nuova con Reset Password.

Solo dopo questi test si disattiva il provider Central o si revocano le assegnazioni dell’app IdP. Dominio, valori del provider, app IdP e Custom Sign-in Rule restano invariati finché accesso, ruoli e Self Service Portal non sono stati confermati tramite il percorso di emergenza. Se questo percorso non funziona, il provider OIDC rimane attivo e si ripristina l’impostazione di accesso precedente.

Le Sign-in Rule, l’accesso Break Glass, il ripristino MFA e il cambio della modalità tenant sono descritti in Proteggere l’accesso a Sophos Central con MFA, passkey e IdP.

Domande frequenti

Sophos Central supporta l'Authorization Code Flow?

Per questo flusso OIDC, la guida Sophos attuale descrive un Implicit Request con response_type=id_token e senza Authorization Code richiesto. L’app del provider deve corrispondere esattamente a questo comportamento documentato.

Il collegamento alla dashboard Okta può essere usato come test?

No. Sophos Central usa un flusso avviato dal service provider. Il test parte dalla pagina di accesso Sophos, così da verificare realmente routing del dominio, request e callback.