Soffid AM

No son lo mismo, aunque suelen desplegarse juntos. El SSO es la funcionalidad que permite iniciar sesión una vez y acceder a varias aplicaciones sin volver a autenticarse; el MFA es el mecanismo que refuerza esa autenticación inicial con un segundo factor (app, token, biometría). Access Management es la plataforma que orquesta ambas cosas, además de las políticas de acceso condicional (desde qué red, dispositivo o riesgo se permite entrar), la gestión del ciclo de vida de las sesiones y la conexión con el resto de aplicaciones vía SAML, OIDC u otros protocolos. Dicho de otra forma: SSO y MFA son piezas; AM es la plataforma que las gobierna.

Se puede y conviene hacer de forma progresiva: no hace falta migrar todas las aplicaciones el mismo día. El enfoque habitual es conectar primero las aplicaciones más críticas o de mayor uso (correo, ERP, herramientas cloud con soporte SAML/OIDC nativo) mientras las aplicaciones más antiguas se van incorporando en fases posteriores, manteniendo el sistema de contraseñas anterior en paralelo solo para las que aún no están migradas. Esto permite mostrar valor (menos contraseñas que recordar, menos tickets de "olvidé mi clave") desde las primeras semanas sin bloquear el proyecto a la espera de resolver la aplicación más difícil de integrar.

Cuando una aplicación no habla SAML ni OIDC de forma nativa, se recurre a mecanismos intermedios: un proxy de autenticación que intercepta la petición y añade la sesión SSO por delante de la aplicación, rellenado automático de formularios de login (form-fill) para aplicaciones cliente-servidor o de escritorio, o un conector a medida que traduce la sesión centralizada al mecanismo propio de la aplicación (por ejemplo, contra su propia base de datos de usuarios). Ninguna de estas vías exige reescribir el código de la aplicación original; se añade una capa de integración por delante o alrededor de ella.

Hay un pico de tickets esperable en las primeras semanas (usuarios que no han instalado la app, que cambian de móvil o pierden el token), pero se puede acotar bastante con una implantación por fases, comunicación previa y más de un método de segundo factor disponible (app, SMS, token físico) para que el usuario elija el que le resulte menos molesto. El verdadero punto de fricción no es el concepto de doble factor, sino los flujos de recuperación mal resueltos: tener un proceso claro de autoservicio o de soporte para "he perdido mi segundo factor" reduce la mayoría de esos tickets desde el primer mes.

Es la objeción técnica más razonable contra el SSO centralizado, y se resuelve con arquitectura, no evitando el SSO. Un despliegue en alta disponibilidad (varios nodos, sin punto único de fallo) reduce drásticamente la probabilidad de una caída total, y además conviene definir accesos de emergencia (break-glass) para cuentas administrativas críticas que no dependan del IdP en el momento exacto del incidente. El riesgo de un IdP caído hay que compararlo, además, con el riesgo actual sin SSO: contraseñas distintas por aplicación gestionadas sin control central no es un escenario más seguro, solo un fallo distribuido en lugar de uno centralizado.

La mayoría de proveedores factura por usuario activo al mes o al año, y algunos añaden un coste por conector para aplicaciones no estándar que requieren desarrollo específico; pocos cobran por aplicación conectada sin más, salvo en integraciones a medida. Para una empresa mediana con SSO y MFA sobre un catálogo de aplicaciones estándar, es habitual moverse en rangos de unos pocos euros por usuario al mes, con el coste de conectores a medida como partida aparte. Con Soffid, al poder autoalojarse, existe además la opción de un modelo de licencia con coste fijo en lugar de recurrente por usuario, lo que puede resultar más previsible para plantillas grandes y estables.

Puedes mantener Active Directory o Azure AD como fuente de identidad y añadir la capa de Access Management por encima, sin migrar las cuentas a otro repositorio. La plataforma de AM se sincroniza con el directorio existente, añade SSO y MFA sobre las aplicaciones conectadas y aplica las políticas de acceso condicional, mientras AD sigue siendo el origen de verdad para usuarios y grupos. La migración completa de identidad solo sería necesaria si se quiere sustituir el propio directorio, algo independiente de añadir SSO/MFA.

Existen alternativas europeas con despliegue on-premise, cloud o híbrido que evitan depender de infraestructura y jurisdicción estadounidense para alojar los datos de identidad. Soffid es una de ellas: es una plataforma europea (española), con raíces open source que permiten autoalojarla completamente si la soberanía del dato es un requisito no negociable, y con certificación Common Criteria y presencia en el catálogo CCN-STIC para el sector público español. Para organizaciones que evalúan Okta, Entra o Ping principalmente por comodidad de mercado, esta es una alternativa a considerar cuando la localización del dato pesa más en la decisión que la cuota de mercado del proveedor.