Configurar OpenID Connect y Okta para el SSO de Sophos Central

Sophos Central puede utilizar un proveedor de OpenID Connect para Single Sign-on iniciado por el SP. El inicio de sesión comienza en Sophos Central, que redirige al usuario al proveedor de identidad. Por tanto, un enlace del dashboard iniciado por el IdP no constituye por sí solo una prueba funcional válida.

Requisitos

Se necesitan un Super Admin, un dominio verificado en Central, un administrador de recuperación probado y un proveedor OIDC que acepte las Authorization Requests que espera Sophos. Todas las cuentas de Central afectadas deben estar asignadas a un dominio y exactamente a un proveedor de identidad.

El dominio se configura antes que el proveedor:

Abrir Global Settings > Access Control > Sign-in and Identity > Sophos Sign-in > Verify domains.
En Federated domains, seleccionar Add domain e introducir el dominio de la organización. example.com es solo un ejemplo y debe sustituirse.
Usar Copy para obtener el registro TXT mostrado, publicarlo en el DNS público y esperar a que se propague. Sophos indica que este proceso puede tardar hasta 24 horas.
En Central, seleccionar Verify domain ownership para el dominio y después Verify. El estado debe mostrar el dominio con la fecha de verificación.

La verificación es válida durante un año y puede renovarse en ese periodo. Su vencimiento debe incluirse en la planificación operativa: que la federación funcione hoy no elimina la necesidad de volver a verificarla.

Central necesita cuatro valores del proveedor:

Campo	Significado
Client ID	identificador público de la aplicación OIDC creada para Sophos Central
Issuer	URL exacta del emisor cuyo valor coincide con el claim `iss` del ID Token
Authz endpoint	endpoint HTTPS para la Authorization Request
JWKS URL	endpoint HTTPS con las claves públicas de firma del proveedor

La Callback URL es exactamente https://federation.sophos.com/login/callback. Sophos solicita openid profile email, response_type=id_token y response_mode=form_post. El proveedor debe entregar un ID Token; Sophos no solicita un Authorization Code en este proceso.

Configurar la aplicación de Okta

En la Okta Admin Console se crea una aplicación en Applications > Create App Integration:

Seleccionar OIDC – OpenID Connect y después Single-Page Application.
Asignar un nombre inequívoco como Sophos Central SSO.
En Grant type, desmarcar el Core Grant Authorization Code.
En Advanced > Other grants, activar Implicit (hybrid).
Introducir https://federation.sophos.com/login/callback como Sign-in redirect URI.
Eliminar las Sign-out redirect URIs existentes.
Limitar inicialmente la asignación a un grupo piloto definido. Sophos muestra como ejemplo sencillo la autorización para todos los usuarios de la organización; para un despliegue seguro, un grupo piloto ofrece mayor control.
Guardar y anotar el Client ID.

El Issuer lo proporciona el Okta Authorization Domain utilizado. Con un Custom Domain, por ejemplo, puede tener el aspecto https://login.example.com. De él se derivan normalmente los siguientes valores:

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

Los valores no se copian de un ejemplo, sino que se comprueban con la configuración de Discovery o del proveedor del tenant de Okta propio. Un Issuer con otro Authorization Server puede contener rutas distintas.

Crear el proveedor en Sophos Central

Abrir Global Settings > Access Control > Sign-in and Identity > Federated identity providers.
Seleccionar Add identity provider e introducir un nombre y una descripción.
Seleccionar Type: Open ID Connect y el Vendor adecuado, por ejemplo Okta.
Introducir exactamente el Client ID, Issuer, Authz Endpoint y JWKS URL.
Seleccionar el dominio verificado. Se permiten varios dominios, pero cada usuario sigue asignado exactamente a uno.
Seleccionar IdP enforced MFA solo si el proveedor garantiza MFA para todas las identidades afectadas. Con No IdP enforced MFA, Central aplica su propia comprobación MFA después de que el IdP autentique correctamente al usuario.
Guardar, volver a abrir el proveedor y activarlo con Turn on cuando la configuración esté completa.

Para Google Workspace, Sophos menciona OIDC como posible proveedor, pero no proporciona en la guía de Central un conjunto de campos completo comparable. Por este motivo, los valores se toman de la configuración OIDC de Google o Cloud Identity realmente utilizada y se validan en el piloto. Las rutas de Okta no se transfieren a Google.

Modo de inicio de sesión y piloto

En Global Settings > Access Control > Sign-in and Identity > Sophos sign-in, primero se selecciona Sophos Central Admin or Federated credentials. Después de guardar, el administrador que realiza el cambio comprueba que Central lo haya añadido automáticamente a una Custom Sign-in Rule con inicio de sesión de Sophos. Esta regla proporciona una vía de recuperación adicional, pero no sustituye a un segundo Super Admin probado por separado.

La prueba positiva comienza en la página de inicio de sesión de Sophos en una sesión privada del navegador. Después de introducir el correo electrónico piloto, el navegador debe redirigir a Okta, solicitar allí la MFA prevista y abrir después el dashboard de Central con el rol esperado. A continuación, se prueban al menos los siguientes casos:

usuario piloto válido con MFA del IdP,
usuario sin asignación de aplicación,
dominio incorrecto o no verificado,
sesión del IdP caducada,
cierre de sesión y nuevo inicio de sesión iniciado por el SP,
segundo Super Admin mediante el método de recuperación.

Solo después de completar correctamente el piloto se considera utilizar Federated credentials only. Asignar una aplicación del IdP a todos los usuarios no sustituye la comprobación de que cada cuenta de Central esté asignada al dominio y al proveedor correctos.

Resolución de problemas

Invalid redirect o bucle de inicio de sesión: comprobar el callback, el tipo de aplicación y el flujo Implicit con ID Token.
Unknown issuer: el valor iss del ID Token debe coincidir exactamente con el campo Issuer de Central.
No se puede comprobar la firma: verificar la JWKS URL, la accesibilidad mediante HTTPS y la clave publicada actualmente.
No se encuentra al usuario: comparar el claim email, el correo electrónico de Central y la asignación de dominio.
No se puede activar el proveedor: los campos obligatorios, el dominio o el formato de las URL están incompletos o no son válidos.
MFA no aparece o aparece dos veces: comprobar conjuntamente la política del IdP y la opción IdP enforced MFA de Central.

Las Sign-in Rules, el acceso de emergencia, la recuperación de MFA y el cambio del modo del tenant se explican en Proteger el inicio de sesión de Sophos Central con MFA, passkeys e IdP.

Preguntas frecuentes

¿Admite Sophos Central el Authorization Code Flow?

La guía actual de Sophos describe para este proceso OIDC una Implicit Request con response_type=id_token y sin solicitar un Authorization Code. La aplicación del proveedor debe ajustarse exactamente a este comportamiento documentado.

¿Puede utilizarse como prueba el enlace del dashboard de Okta?

No. Sophos Central utiliza un proceso iniciado por el SP. La prueba comienza en la página de inicio de sesión de Sophos para comprobar realmente el enrutamiento del dominio, la solicitud y el callback.