SSO de empresa (OIDC, SAML) 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)
• SSO de empresa (SAML 2.0)

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

El ajuste lo aplica el servidor, no solo la página de inicio de sesión: un inicio de sesión con contraseña a través de la API o de la aplicación móvil se rechaza, y ¿Olvidaste tu contraseña? no envía ningún enlace. Los administradores de la empresa y las excepciones anteriores conservan su acceso. Las cuentas de API, autenticadas por token, no se ven afectadas.

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

Configuración del SSO de empresa (SAML 2.0)

Para los proveedores de identidad que solo hablan SAML — AD FS anterior a Windows Server 2016, o SAML impuesto por su política de seguridad — y para cualquier proveedor SAML 2.0: Entra ID, Okta, Keycloak, Shibboleth… Una vez conectado, el usuario obtiene exactamente la misma sesión que con OIDC.

En el formulario SSO de FoxPlan, elija el proveedor SAML 2.0 y facilite preferentemente los metadatos del proveedor:

• URL de los metadatos — para AD FS: https://<servidor-adfs>/FederationMetadata/2007-06/FederationMetadata.xml. Se vuelve a leer en cada conexión: un certificado de firma renovado en el proveedor se tiene en cuenta sin intervención.
• o los metadatos XML pegados, si el servidor FoxPlan no puede acceder a esa URL. Un XML ilegible se rechaza al guardar. Vuelva a pegarlo cuando el proveedor renueve su certificado.

Los metadatos aportan el entity ID, la URL SSO y el certificado de firma del proveedor. Sin ellos, rellene estos tres campos a mano.

En el proveedor de identidad, declare FoxPlan con los valores que muestran la pantalla y Verificar la configuración:

Dato	Valor
Identificador de FoxPlan (entity ID, Relying party identifier)	{origin}/saml2/service-provider-metadata/{registrationId}
URL de retorno (ACS, binding HTTP-POST)	{origin}/login/saml2/sso/{registrationId}
Metadatos de FoxPlan	La misma URL que el identificador: sirve el archivo de metadatos, importable tal cual (AD FS: «Import data about the relying party published online»)

{registrationId} vale <identificador de la empresa>-saml2.

Atributos. FoxPlan vincula al usuario con su cuenta por su email. Lo busca en el atributo indicado en las opciones avanzadas, luego en los nombres habituales — email, mail, la URI de AD FS http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress, el OID LDAP urn:oid:0.9.2342.19200300.100.1.3, el UPN — y, en su defecto, en el NameID si tiene forma de dirección. Nombre y apellido siguen la misma lógica (givenName, surname, URI de AD FS). Sin email, la conexión se rechaza.

Con AD FS, añada a la relación de confianza una regla de emisión «Send LDAP Attributes as Claims»: E-Mail-Addresses → E-Mail Address, Given-Name → Given Name, Surname → Surname.

Binding. La solicitud de autenticación sale por defecto en HTTP-Redirect; HTTP-POST sigue disponible. La respuesta del proveedor vuelve siempre en HTTP-POST.

No compatible: la firma de las solicitudes de autenticación, el cifrado de las aserciones y el cierre de sesión SAML (Single Logout). En AD FS, no declare un certificado de cifrado en la relación de confianza y no exija solicitudes firmadas.

Instalación on-premise

El servidor FoxPlan descarga él mismo los metadatos del proveedor. Si los sirve un AD FS interno cuyo certificado está firmado por la PKI de la empresa, deposite el certificado de esa autoridad en ca-sortant/ — vea Certificados entrantes y salientes.

Aprovisionamiento de usuarios y grupos AD

El aprovisionamiento permite que su directorio (Active Directory, Entra ID, Okta, Keycloak…) dirija FoxPlan. Funciona con OIDC y con SAML 2.0, y por tanto con AD FS.

• Cuentas creadas en la primera conexión. Un usuario desconocido para FoxPlan, miembro de al menos un grupo AD asociado a un grupo FoxPlan, recibe una cuenta en su primera conexión SSO, sin invitación. Entra en el espacio de trabajo de ese grupo como Miembro del espacio de trabajo: sin derechos ni licencia. El administrador le asigna después un rol.
• Grupos sincronizados en cada conexión. Los grupos FoxPlan asociados siguen los grupos AD del usuario: los une o los deja en cada conexión. Estos grupos configuran su interfaz — menús, funciones, favoritos compartidos, modelos de proyecto.

Grupos y roles siguen separados: el aprovisionamiento nunca modifica un rol. Un usuario que no pertenece a ningún grupo asociado es rechazado, como sin aprovisionamiento. Un usuario eliminado en FoxPlan no se vuelve a crear por el SSO.

Activar el aprovisionamiento — en la configuración SSO, panel Aprovisionamiento de usuarios:

• marque Crear las cuentas y sincronizar los grupos en la conexión;
• Atributo de los grupos: déjelo vacío para reconocer los nombres habituales (groups, memberOf, notificaciones Group y Role de AD FS), o indique el atributo (SAML) o el claim (OIDC) de su proveedor.

Asociar los grupos — en la pestaña Acceso de usuarios → Grupos del espacio de trabajo, edite un grupo y rellene Grupos AD asociados, uno por línea. Un grupo AD se designa por su nombre (Finance, CONTOSO\Finance) o por su identificador (GUID de Entra). La comparación ignora mayúsculas y el prefijo de dominio, y solo conserva el CN de un DN LDAP. Los grupos por defecto no se asocian: sus miembros derivan de los roles.

Una cuenta aprovisionada también es miembro del grupo por defecto All users. Sus menús y funciones son la intersección de All users y de sus grupos sincronizados: un grupo AD solo puede restringir, nunca ampliar. Configure All users de forma amplia y restrinja en los grupos asociados al AD.

En la lista de miembros, una etiqueta AD señala a quienes solo están por la sincronización. Siguen al AD, no a la pantalla. Un miembro añadido a mano nunca se retira por la sincronización.

En el proveedor de identidad, transmita los grupos del usuario:

Proveedor	Ajuste
AD FS	Regla de emisión «Send Group Membership as a Claim», o «Send LDAP Attributes as Claims»: Token-Groups – Unqualified Names → Group
Entra ID	Token configuration → Add groups claim. Entra envía el identificador (GUID) de los grupos y, por encima de 200 grupos, deja de enviar la lista: limite la emisión a los grupos asignados a la aplicación
Okta	Groups claim filtrado a los grupos útiles
Keycloak	Mapper Group list (SAML) o Group Membership (OIDC)

Bajas

Con el solo aprovisionamiento en la conexión, una baja en el AD solo se tiene en cuenta en la siguiente conexión del usuario. SCIM, a continuación, la aplica de inmediato. Si no, elimine al usuario en FoxPlan.

Con AD FS, desmarque también Contraseña en los métodos de inicio de sesión: una cuenta desactivada en el AD ya no podrá entrar de ninguna forma, como muy tarde al expirar su sesión de FoxPlan (24 h).

Aprovisionamiento automático por SCIM (Entra ID, Okta)

Con Entra ID u Okta, el directorio también puede enviar por sí mismo usuarios y grupos a FoxPlan, sin esperar a su conexión: es el protocolo SCIM 2.0. Las reglas son las del aprovisionamiento en la conexión — cuenta creada como Miembro del espacio de trabajo solo para los miembros de un grupo asociado, roles nunca modificados. SCIM añade las bajas inmediatas: un usuario desactivado, o retirado de la aplicación en el directorio, pierde su acceso al instante.

1. En Ajustes → Empresa → Aprovisionamiento (SCIM), haga clic en Generar un token y cópielo: no volverá a mostrarse, FoxPlan solo guarda su huella.
2. En el directorio:
   • Entra ID: Aplicaciones empresariales → su aplicación FoxPlan → Aprovisionamiento, modo Automático. Tenant URL: la URL que muestra FoxPlan (https://<su-dominio>/scim/v2); Secret Token: el token. Probar conexión, asigne usuarios y grupos a la aplicación y después inicie el aprovisionamiento.
   • Okta: la aplicación → Provisioning → SCIM. SCIM connector base URL: la URL; Unique identifier field: userName; acciones Push New Users, Push Profile Updates y Push Groups; autenticación HTTP Header con el token.
3. Asocie los grupos FoxPlan a los grupos enviados, por nombre o identificador, como se describe más arriba.

En el directorio	En FoxPlan
Usuario asignado a la aplicación	En espera; cuenta creada en cuanto pertenece a un grupo asociado
Añadido a un grupo, o retirado	Se une o deja los grupos FoxPlan asociados
Desactivado, o retirado de la aplicación	Cuenta desactivada al instante: sin conexión, retirado de los espacios
Reactivado	Cuenta restaurada

La pestaña conserva el registro de llamadas durante 90 días. Un usuario enviado cuyo email coincide con una cuenta FoxPlan existente queda vinculado a ella: desactivarlo en el directorio también desactiva esa cuenta. Regenerar o revocar el token detiene el aprovisionamiento de inmediato, sin tocar las cuentas ya creadas.

Instalación on-premise

Aquí es el directorio el que llama a FoxPlan, por el puerto 443 y la ruta /scim/v2. Entra ID y Okta son servicios en línea: la URL debe ser accesible desde Internet, salvo que use su agente de aprovisionamiento instalado en su red.

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)