Sustituir AD FS y cambiar el protocolo de autenticación de una aplicación son decisiones distintas. Una aplicación que ya utiliza WS-Federation podría conservar ese protocolo al cambiar su identity provider de confianza por FoxIDs.
El primer hito útil es una aplicación que reconozca a los mismos usuarios, conceda el acceso previsto y disponga de una vía de retorno probada. Un inicio de sesión correcto no demuestra, por sí solo, ninguno de esos resultados.
Esta guía está dirigida a arquitectos de IAM y de soluciones que preparan esa primera migración. Abarca una aplicación basada en navegador que utiliza WS-Federation pasivo, a menudo abreviado como WS-Fed. La federación de dominios de Microsoft 365, el inicio de sesión en Windows y los clientes activos de WS-Trust requieren su propia evaluación y quedan fuera de este ejemplo.
Separe el traslado de la aplicación del traslado del directorio
AD FS es un servicio de federación; Active Directory es el directorio contra el que autentican muchas instalaciones de AD FS. Trasladar la relación de confianza de federación de una aplicación no traslada, por sí mismo, las cuentas ni las contraseñas del directorio.
Un posible patrón de transición mantiene inicialmente AD FS como fuente de autenticación:
| Etapa | En qué confía la aplicación | Dónde se autentica el usuario |
|---|---|---|
| Antes | AD FS emite el token WS-Federation de la aplicación | AD FS utiliza su configuración de autenticación existente |
| Primer piloto | FoxIDs emite un nuevo token WS-Federation para la aplicación | FoxIDs dirige el navegador a AD FS mediante un método de autenticación configurado |
| Un cambio posterior e independiente | La aplicación sigue confiando en FoxIDs | Otro identity provider externo, o FoxIDs Login con Directory Connector para AD, sustituye a AD FS después de una validación independiente |
FoxIDs admite tanto un registro de aplicación WS-Federation orientado a la aplicación como un método de autenticación WS-Federation orientado a AD FS. Ambos lados tienen funciones distintas: uno emite tokens y el otro valida la respuesta del proveedor de origen.
En el piloto, AD FS emite un token destinado a FoxIDs. FoxIDs lo valida y emite un token diferente destinado a la aplicación. No se trata de reenviar de forma transparente el token anterior: la aplicación debe confiar en el emisor y el certificado de firma de FoxIDs.
El piloto sigue dependiendo de AD FS. Proporciona un punto controlado en el que verificar la relación de confianza y los requisitos de claims de la aplicación, pero todavía no retira el servicio de federación.
Dos vías para prescindir de AD FS
Después del piloto, son posibles estas dos vías:
- Mantener un identity provider externo. Sustituya AD FS por otro IdP conectado a FoxIDs mediante un método de autenticación compatible. FoxIDs sigue siendo el emisor WS-Federation de confianza de la aplicación, por lo que esta no tiene que adoptar el protocolo del nuevo proveedor.
- Utilizar FoxIDs Login con Active Directory. El Directory Connector para Active Directory valida las contraseñas contra AD. Esto elimina AD FS de la ruta de inicio de sesión de la aplicación, manteniendo AD como directorio autoritativo. La guía de modernización de Active Directory explica esta arquitectura.
Pasar posteriormente a la validación de contraseñas en FoxIDs es opcional. Los inicios de sesión correctos a través del conector crean o actualizan usuarios internos de FoxIDs y, cuando está activado el almacenamiento local de contraseñas, guardan un hash de la contraseña para preparar a esos usuarios para un cut-over posterior. Se trata de una migración gradual, no de una exportación de todas las cuentas de AD; AD sigue siendo la fuente autoritativa mientras el conector esté activado.
Sea cual sea la vía elegida, vuelva a probar las asociaciones de cuentas, los claims, MFA y logout. El piloto de la primera aplicación que se describe a continuación establece qué debe conservarse.
Documente lo que consume realmente la primera aplicación
Elija una aplicación con un responsable, un entorno de pruebas representativo y una configuración que pueda restaurar. Confirme que su middleware o proveedor admite cambiar el STS de confianza, abreviatura de Security Token Service. Una URL de metadatos configurable resulta útil, pero también importan las comprobaciones personalizadas del emisor, el código de búsqueda de cuentas y las reglas de autorización.
Considere una aplicación ficticia de gestión de gastos. La tabla siguiente ilustra los requisitos que debe cumplir el resultado; no es una configuración exportada ni un informe de una migración completada.
| Elemento | Comportamiento existente | Resultado requerido en el piloto |
|---|---|---|
| Realm / audience | urn:example:expenses identifica la aplicación |
El wtrealm de la aplicación coincide con su registro en FoxIDs y el token está destinado a esa aplicación |
| URL de respuesta | La instancia de pruebas recibe respuestas en https://expenses-test.example.org/signin-wsfed |
Solo se acepta y utiliza el callback previsto para las pruebas |
| Emisor de confianza y claves de firma | La aplicación confía en los metadatos y las claves de firma de AD FS | La instancia de pruebas confía en los metadatos, el emisor y las claves de firma de FoxIDs seleccionados para este piloto |
| Formato del token | El middleware acepta SAML 1.1 transportado mediante WS-Federation | Mantener ese formato de token, salvo que sea necesario un cambio probado por separado |
| Búsqueda de usuarios | El claim NameIdentifier de la aplicación identifica al empleado E1042 |
Se seleccionan la misma cuenta existente y su historial; no se crea una segunda cuenta |
| Autorización | El rol ExpenseApprover permite aprobar gastos |
Los usuarios autorizados conservan ese permiso; los usuarios sin el rol siguen sin poder aprobar |
| Comportamiento de las sesiones | La aplicación tiene una cookie local y una política de logout definida | El inicio de sesión, la caducidad, una nueva autenticación y logout cumplen la política acordada a través de la nueva ruta |
Utilice los valores y tipos de claims de la aplicación real al completar esta tabla. Compruebe si la búsqueda de cuentas incluye también el emisor del token o el nombre del proveedor externo de inicio de sesión: conservar únicamente el identificador de usuario visible puede no preservar la asociación con la cuenta.
FoxIDs puede emitir tokens SAML 1.1 o SAML 2.0 a través de WS-Federation; SAML 1.1 es el valor predeterminado. Un token SAML 2.0 dentro de una respuesta WS-Federation no supone cambiar al protocolo SAML 2.0 Web SSO. Mantenga separadas las decisiones sobre el protocolo y el formato del token.
Documente los requisitos de cifrado y la caducidad de los certificados junto con la confianza en la firma. El cifrado y la validación de firmas resuelven problemas distintos, y la compatibilidad debe ajustarse a la aplicación receptora. Para ASP.NET Core, la guía de Microsoft sobre el middleware WS-Federation identifica MetadataAddress, Wtrealm y la configuración del callback como ajustes de integración relevantes. Compruebe el middleware y la versión que utiliza antes de aplicar un ejemplo de configuración.
Configure ambos lados en un entorno de pruebas
Cree el piloto en un entorno de FoxIDs independiente y utilice una instancia de pruebas de la aplicación. Configure la conexión con AD FS como método de autenticación y registre después la aplicación existente en FoxIDs con su realm, URL de respuesta, tipo de token y claims necesarios.
En AD FS, FoxIDs es una relying party por derecho propio. Establezca esa relación de confianza utilizando los metadatos del método de autenticación de FoxIDs y defina los claims y la política de acceso que AD FS debe aplicarle. Mantenga disponible la relación de confianza original de la aplicación en AD FS durante la ventana de rollback acordada.
No dé por hecho que las reglas de claims, las restricciones de acceso o la política de MFA de la relying party original se aplican automáticamente a esta nueva relación de confianza. Las reglas de claims de AD FS se asocian a relaciones de confianza individuales, como explica Microsoft en su guía sobre reglas de claims. Reproduzca el comportamiento necesario en el punto adecuado y pruébelo.
A continuación, configure la instancia de pruebas de la aplicación para utilizar los metadatos del STS de FoxIDs y el emisor esperado. Mantenga activada la validación del emisor, audience y firma. Utilice los endpoints generados para el entorno real en lugar de adaptar manualmente una URL de AD FS.
El piloto de navegador pasivo no necesita la opción independiente Microsoft Entra ID Windows sign-in. Esa función admite un escenario distinto de federación de dominios y clientes activos.
Siga los claims hasta la aplicación
Los metadatos establecen los endpoints y la información de confianza; no determinan cómo se comportan las cuentas y los permisos de la aplicación.
Con un método WS-Federation conectado al proveedor de origen, FoxIDs recibe claims SAML, los representa internamente como claims JWT y los vuelve a convertir en claims SAML para el token de la aplicación. Por ejemplo, el mapping predeterminado convierte http://schemas.microsoft.com/ws/2008/06/identity/claims/role en role internamente y después de nuevo en el tipo de claim SAML para WS-Federation. Incluya el tipo de claim SAML del rol requerido tanto en la lista Forward claims del método de autenticación como en la lista Issue claims de la aplicación; los roles no forman parte del conjunto predeterminado de claims.
Los identificadores requieren una comprobación independiente. Para un método de autenticación WS-Federation llamado adfs, FoxIDs añade un prefijo al identificador recibido E1042, de modo que pasa a ser adfs|E1042 antes de las transformaciones de claims posteriores. Si la aplicación de gastos espera E1042, defina un mapping explícito que preserve la asociación con la cuenta existente. No elimine prefijos indiscriminadamente: identificadores iguales de fuentes distintas podrían seleccionar la misma cuenta.
Compare a un usuario que ya puede aprobar gastos con un empleado que no deba hacerlo. Examine los claims que consume realmente la aplicación, incluido cualquier mapping del middleware, y pruebe los permisos resultantes. Las transformaciones de claims pueden cambiar nombres y valores, por lo que debe verificar el resultado final, no solo la configuración.
Consulte la documentación sobre transformaciones de claims y mapping para los detalles de implementación. Reenvíe y emita los claims que necesita la aplicación; un comodín no sustituye la decisión sobre qué datos debe recibir.
Pruebe el acceso y la denegación antes del cut-over
Acuerde los resultados esperados con el responsable de la aplicación antes de las pruebas. Registre tanto el token y los claims observados como el comportamiento de la aplicación, utilizando cuentas de prueba y excluyendo el material de autenticación de los informes compartidos.
| Prueba | Evidencia necesaria antes de continuar |
|---|---|
| Un usuario existente inicia sesión | Se seleccionan la cuenta existente de la aplicación, sus datos y su historial |
| Un aprobador y un empleado ordinario realizan la misma acción | El aprobador puede completarla; al empleado ordinario se le deniega |
| Un usuario está excluido por la política de acceso de la aplicación anterior | La nueva ruta sigue denegando el acceso a ese usuario |
| Se requiere MFA, incluso con una sesión de navegador de AD FS existente | El flujo configurado cumple el nivel de garantía requerido; un inicio de sesión correcto en el proveedor de origen no se acepta por sí solo como evidencia suficiente |
| El usuario cierra sesión y vuelve a visitar una página protegida | La cookie de la aplicación, la sesión de AD FS y el flujo configurado de logout/cleanup cumplen la política de logout acordada |
| Un nuevo intento de autenticación requiere AD FS mientras AD FS no está disponible | El intento falla sin omitir la fuente de autenticación requerida; el responsable operativo puede ver el fallo |
| Las respuestas de prueba contienen un emisor, audience o firma no válidos | Se rechaza cada respuesta no válida; la validación permanece activada |
| Se restaura la configuración anterior de la aplicación | Un nuevo inicio de sesión por la ruta original de AD FS selecciona la cuenta y los permisos correctos |
Pruebe la caducidad de las sesiones y una nueva autenticación por separado de un inicio de sesión correcto ordinario. Una cuenta deshabilitada o un usuario al que se le haya retirado un rol puede seguir teniendo una sesión existente en la aplicación. Acuerde cuándo debe terminar el acceso y verifique ese plazo, en lugar de suponer que una nueva configuración de federación revoca todas las cookies.
FoxIDs admite sign-out y notificaciones de cleanup de WS-Federation cuando están configurados. Que todas las aplicaciones participantes borren su sesión local depende de su implementación y del flujo real del navegador. Compruebe el comportamiento de logout con los clientes y navegadores utilizados en producción.
Haga del cut-over una decisión acotada y reversible
Antes de pasar a producción, documente quién puede restaurar la configuración anterior de la aplicación, dónde se guarda y qué hallazgos activan el rollback. Las asociaciones de cuentas incorrectas, los permisos no previstos y los requisitos de MFA incumplidos deben detener el despliegue de inmediato. Acuerde umbrales para los fallos de inicio de sesión y las incidencias operativas en lugar de improvisarlos durante el cambio.
Realice la migración de la aplicación dentro del alcance acordado y durante una ventana supervisada. Un piloto usuario a usuario solo es posible si la aplicación y el diseño del enrutamiento lo admiten; en caso contrario, utilice primero la instancia de pruebas y trate la aplicación de producción como la unidad de cambio.
El rollback debe abarcar más que la URL de metadatos. Restaure la confianza anterior en el emisor y las claves, la configuración de claims y cualquier asociación de cuentas modificada durante el piloto. Decida cómo finalizar o sustituir las sesiones establecidas por la nueva ruta. Restaurar el endpoint anterior no deshace los cambios en los datos de la aplicación ni elimina automáticamente esas sesiones.
Una vez estabilizada esta aplicación, decida qué dependencia eliminar a continuación. Sustituir AD FS como proveedor de origen, cambiar el protocolo de la aplicación a OpenID Connect y migrar los usuarios del directorio son cambios posteriores independientes, cada uno con sus propias pruebas. Si va a cambiar el almacenamiento de usuarios o contraseñas, utilice la guía de decisión sobre migración de contraseñas en lugar de incorporar ese trabajo a este piloto.
El resultado medido de la primera aplicación ofrece un punto de partida concreto para la siguiente migración: una configuración de confianza comprendida, un comportamiento de usuarios y accesos verificado y un procedimiento de recuperación que el equipo ha practicado. Utilice la guía de migración para convertir esa evidencia en un plan más amplio.