SSO de empresa (OIDC) y autenticación multifactor (MFA)

Ubicación de la configuración

Los administradores de empresa acceden a estos parámetros desde Ajustes → Empresa, en las pestañas Métodos de conexión y Doble autenticación.

VPN, proxy o firewall corporativo

Si sus usuarios inician sesión detrás de una VPN, un proxy corporativo o un firewall con inspección SSL, algunos flujos del SSO pueden bloquearse o alterarse (cookie de estado eliminada, dominios de identidad inaccesibles). El síntoma típico es un inicio de sesión que falla o entra en bucle — mientras que el SSO funciona sin la VPN. Comparta la matriz de flujos de red con su equipo de red para permitir los dominios necesarios sin inspección SSL ni reescritura de cookies.

Métodos de conexión disponibles

FoxPlan admite varios enfoques de autenticación:

• Contraseña
• Google Sign-in
• Microsoft Sign-in
• SSO de empresa (OIDC)

Importante

Los administradores de empresa conservan siempre la conexión por contraseña, incluso cuando está desactivada para la empresa. Esto evita quedarse bloqueado fuera de FoxPlan si el proveedor de identidad deja de estar disponible.

Excepciones: conservar la contraseña para determinados usuarios

Cuando migra su organización al SSO, puede desactivar la conexión por contraseña para todo el mundo salvo una lista de usuarios designados.

Desmarque Contraseña: aparece entonces un selector «Excepciones: usuarios que conservan la contraseña» debajo de las casillas. Elija en él los usuarios afectados y, a continuación, guarde.

Estos usuarios seguirán viendo el campo de contraseña en la pantalla de conexión, mientras que todos los demás deberán pasar por el SSO o por la conexión Google/Microsoft.

Casos de uso típicos:

• Cuentas de emergencia («break-glass») en caso de avería del proveedor de identidad
• Proveedores o externos ausentes de su directorio de empresa
• Migración progresiva: pasar los equipos al SSO por oleadas

consejo

El selector solo es visible si el método Contraseña está desmarcado: mientras esté activo, ya se aplica a todo el mundo y no es necesaria ninguna excepción.

Opciones de MFA

Las organizaciones pueden elegir entre:

• TOTP (compatible con Google Authenticator, Microsoft Authenticator, Okta, Keycloak)
• Verificación por correo electrónico
• Sin MFA

Perímetro: a quién se aplica la doble autenticación

En cuanto se selecciona un método (TOTP o Email), una sección «Se aplica a» permite elegir la población afectada:

Opción	Efecto
Todos los usuarios	La doble autenticación se impone a toda la empresa (comportamiento por defecto).
Solo los usuarios listados	Solo los usuarios seleccionados pasan por la doble autenticación.
Todos los usuarios salvo los listados	La doble autenticación se aplica en todas partes, salvo para los usuarios seleccionados.

Para los dos últimos modos, un selector permite designar a los usuarios afectados.

Casos de uso típicos:

• Despliegue progresivo: empezar por «Solo los usuarios listados» con un equipo piloto y pasar después a «Todos los usuarios».
• Refuerzo selectivo: exigir la doble autenticación únicamente a los administradores y los perfiles sensibles.
• Exclusiones técnicas: dispensar a las cuentas que no pueden responder a un desafío MFA (cuentas de servicio, terminales compartidos) mediante «Todos los usuarios salvo los listados».

El perímetro se aplica en el servidor: un usuario fuera del perímetro se conecta directamente, sin desafío MFA, aunque haya un método activo para la empresa.

precaución

En el modo «Todos los usuarios salvo los listados», cada usuario excluido constituye un debilitamiento del nivel de seguridad. Revise esta lista con regularidad.

Flujo de conexión

1. El usuario introduce su correo electrónico y continúa
2. FoxPlan identifica la empresa asociada
3. Se muestran los métodos de autenticación disponibles para esa organización
4. El usuario elige Contraseña o SSO según las opciones activadas

Para los flujos por contraseña, se aplican los desafíos MFA. Los flujos SSO delegan la autenticación en el proveedor de identidad.

Configuración del SSO de empresa (OIDC)

FoxPlan admite los proveedores OIDC: Okta, Keycloak, Google, Microsoft e implementaciones personalizadas.

En el lado del proveedor de identidad:

• Crear una aplicación OIDC de tipo Web
• URL de redirección: {origin}/login/oauth2/code/{registrationId}
• Recopilar el Client ID, el Client Secret (o el certificado, ver más abajo) y el Issuer URI

En el formulario SSO de FoxPlan:

• Selección del proveedor
• Nombre para mostrar
• Client ID
• Autenticación del cliente: secreto compartido o certificado
• Issuer URI
• Scopes: openid,profile,email
• Atributo username (normalmente sub o email)
• Interruptor de activación

Autenticación del cliente: secreto o certificado

El intercambio del código de autorización por un token es la única llamada que FoxPlan dirige directamente al proveedor de identidad, de servidor a servidor. FoxPlan debe identificarse en ella, y el campo Autenticación del cliente ofrece dos maneras de hacerlo.

Secreto de cliente (por defecto). Un secreto compartido, introducido en ambos lados. Es el modo histórico, y nada cambia para las configuraciones existentes: sin elección explícita, siguen así.

Certificado (clave privada). FoxPlan firma una aserción JWT con una clave privada y el proveedor la verifica con el certificado público que usted ha declarado allí (private_key_jwt, RFC 7523). El secreto no circula entonces nunca por la red, razón por la cual muchos departamentos de informática prohíben hoy los secretos de cliente.

Aparecen entonces dos campos:

• Certificado de cliente: el certificado X.509 en formato PEM. Es la mitad pública, que también debe cargarse en su proveedor de identidad (en Entra ID: Certificates & secrets → Certificates).
• Clave privada: en formato PKCS#8 sin cifrar, el que empieza por -----BEGIN PRIVATE KEY-----. Una clave PKCS#1 (BEGIN RSA PRIVATE KEY) o protegida por contraseña se rechaza, indicando el comando de conversión que hay que aplicar.

Para generar un par:

openssl req -x509 -newkey rsa:2048 -keyout clave.pem -out certificado.pem -days 730 -nodes -subj "/CN=foxplan-sso"
openssl pkcs8 -topk8 -nocrypt -in clave.pem -out clave-pkcs8.pem

Declare certificado.pem en el proveedor y pegue clave-pkcs8.pem en FoxPlan.

La clave privada se cifra en la base de datos, la API nunca la devuelve y no se vuelve a mostrar en pantalla: al modificar, dejar el campo vacío conserva la clave guardada. El certificado, en cambio, es público y sigue visible.

Un certificado caduca

A diferencia de un secreto, un certificado tiene fecha de fin. Pasada esa fecha, el SSO se detiene en seco.

Por eso la fecha de caducidad se muestra de forma permanente: la lista de configuraciones incluye una columna Autenticación que indica, para cada SSO, si se autentica con secreto o con certificado, y en este último caso la fecha de caducidad, en naranja durante el mes anterior y en rojo una vez pasada. Esa fecha nunca se introduce a mano: se lee del propio certificado cada vez que se muestra, la única fuente que no puede divergir de la realidad. Verificar la configuración ofrece el detalle completo, huella incluida.

Configuración por proveedor

Google — Issuer URI: https://accounts.google.com

Microsoft / Azure — Issuer: https://login.microsoftonline.com/{tenantId}/v2.0

Okta — Aplicación de tipo Web con la asignación y las políticas de acceso adecuadas

Keycloak — Issuer URI del realm, flujo Authorization Code configurado

Recibir un aviso antes de la caducidad

Mostrar la fecha supone que alguien vaya a mirarla. Por eso FoxPlan avisa por su cuenta: se envía un correo a los administradores de la empresa en tres momentos — treinta días, siete días y el día en que el certificado ha caducado. El mensaje nombra el proveedor afectado, indica la fecha y remite a la pantalla de configuración.

Cada umbral se anuncia una sola vez: el barrido recuerda lo que ya ha enviado. En cuanto se renueva el certificado — cuando la caducidad vuelve a superar los treinta días — el contador se rearma solo para el certificado siguiente. No hay nada que hacer.

Si no hay ningún administrador de empresa declarado, no sale ningún correo: una razón más para mantener esa lista al día en los miembros de la empresa.

Cuando la conexión falla

El usuario cuya conexión SSO falla vuelve a la pantalla de conexión con una frase que nombra la causa, y no con un código devuelto por el proveedor de identidad:

Lo que ve el usuario	Qué hay que hacer
El certificado de conexión ha caducado	Renovar el certificado y volver a cargarlo en ambos lados
El certificado no se puede utilizar	Comprobar que la clave privada corresponde al certificado
El proveedor ha rechazado las credenciales de FoxPlan	El secreto se cambió en el proveedor, o el certificado no está declarado allí
Ninguna conexión SSO activa	La configuración está desactivada o no existe
El proveedor ha denegado el acceso	La cuenta no está autorizada en la aplicación del lado del proveedor

El detalle técnico — mensaje exacto del proveedor, traza completa — permanece en los registros del servidor, para el soporte. El usuario recibe una frase que le dice a quién dirigirse.

Verificar la configuración antes de probar

Cada configuración de la lista incluye un botón Verificar la configuración. Abre un informe que no sale de la pantalla y que no intenta ninguna conexión:

• las URL que hay que declarar en el proveedor de identidad, con un botón de copia: la URL de redirección y la URL de inicio de la conexión. Son exactamente las que utilizará la aplicación, así que no hace falta reconstruirlas a mano;
• los controles de coherencia: campos obligatorios cumplimentados, documento de descubrimiento leído desde el servidor, emisor y puntos de acceso conformes con lo que publica el proveedor. Con autenticación por certificado, el informe comprueba además que la clave privada corresponde al certificado, muestra la huella SHA-1 —la que aparece en la consola del proveedor— y señala un certificado caducado o próximo a caducar.

Tres niveles: verde cuando es conforme, naranja para un punto que conviene mirar, rojo para lo que impedirá la conexión. El detalle mostrado a la derecha de cada línea es el dato en bruto —URL, estado HTTP, mensaje del proveedor—, el que se transmite al soporte.

Un control puede señalarse como «URL no sondeada»: el servidor solo llama a direcciones públicas en https, y la configuración no es la causa.

Este informe es de solo lectura: nunca modifica la configuración.

Solución de problemas

Compruebe estos elementos en caso de problema de autenticación:

• La URL de redirección coincide exactamente entre el IdP y FoxPlan
• La configuración SSO está efectivamente activada
• El correo electrónico del usuario pertenece a la empresa correcta
• Para Okta/Azure/Keycloak, verifique la asignación y la conformidad con las políticas
• Para los usuarios con Contraseña+MFA, verifique el enrolamiento (secreto TOTP o correo electrónico válido)