Migrar aplicaciones o sistemas legacy de .NET Framework a .NET moderno o .NET Core cada vez es más fácil; existen un conjunto de herramientas que ayudan a esta tarea. Por ejemplo, Microsoft y la comunidad, desde los inicios de .NET Core, complementó con el clásico “.NET Upgrade Assistant”. Ahora, recientemente, han agregado a Copilot contexto para que pueda ayudar a esta labor con “Copilot App Modernization”.

Sin embargo, existen aún muchas aplicaciones que se pueden considerar legacy, usando el clásico .NET Framework, ya sea en sus versiones NET 4.5, 4.7 ó 4.8, y aunque no hay estadísticas ni cifras oficiales, esto se puede inferir por el conocimiento que se pide en convocatorias y por los temas que buscan los desarrolladores.

Si actualmente, o en algún momento, tuviste la oportunidad de lidiar con un sistema o aplicación legacy grande en .NET Fx con muchos módulos, es muy probable que tu equipo se haya planteado la migración a .NET moderno/.NET Core. En este tipo de escenarios, donde la operatividad depende de una aplicación grande y no se puede parar, un enfoque de migración progresivo con un patrón de estrangulamiento se suele recomendar; es decir, se empieza a migrar módulo por módulo, garantizando la convivencia con el sistema legacy mientras se van apagando las partes migradas.

Uno de los principales retos en este tipo de estrategias es cómo lograr una convivencia entre la parte legacy y los módulos migrados, garantizando la mejor experiencia posible de cara al usuario; por ejemplo, que el usuario no tenga que iniciar sesión dos veces: una vez para la parte legacy y otra vez para los módulos migrados.

En este artículo hablo sobre una alternativa para lograr esta convivencia con una experiencia de un solo inicio de sesión, o SSO por sus siglas en inglés (Single Sign On). En el siguiente diagrama se puede apreciar la propuesta de implementación:

Esta propuesta se puede explicar a alto nivel de la siguiente manera:

• Es una implementación transitoria que busca garantizar la convivencia entre .NET legacy y .NET moderno sin modificar el sistema legacy a profundidad.
• Un proxy recibe las peticiones de los usuarios. Ya sea que el usuario haya ingresado a cualquiera de los módulos legacy o moderno, primero tendrá que iniciar sesión; este inicio de sesión le crea la cookie compartida.
• La redirección o ruteo a los módulos está basado en un dominio compartido y rutas relativas. Para implementar el proxy se puede usar un Azure Front Door o uno propio con .NET Yarp, e incluso Envoy.
• Para poder generar una cookie compartida con un cifrado que todos los módulos puedan leer, tanto el sistema legacy como el moderno deben conocer la clave de cifrado; para esto se usa un storage central, que puede ser un directorio compartido del sistema de archivos o Azure Blob Storage. Depende de dónde se estén implementando las aplicaciones, si en Cloud o en OnPremise.
• Para garantizar seguridad web y protección CSRF, la cookie debe ser segura, HttpOnly y SameSite estricto.
• Cumpliendo estos puntos, el usuario tendrá que iniciar sesión solo una vez, ya que al entrar al siguiente módulo tendrá toda la capacidad para leer la cookie de sesión.

Ahora vamos al código.

¿Qué debo hacer en .NET Framework?

• La aplicación .NET Fx debe implementar OWIN-Katana Middleware con autenticación por cookies.
• Con el uso del paquete NuGet Microsoft.Owin.Security.Interop se agrega al proyecto las capacidades AspNetCore, como DataProtection, esencial para el manejo de claves y cifrado de cookies.
• Implementar un código como el siguiente en una clase Startup: entre las líneas 24 y 27 se crea el “DataProtectionProvider” basado en AspNetCore DataProtection, indicándole el directorio compartido. Luego, como parte fundamental para la interoperabilidad, el provider debe crear el protector dentro de la clase “DataProtectorShim”. Para finalizar, con la clásica implementación de cookies con “UseCookieAuthentication”, pero configurando el parámetro “TicketDataFormat”, vital para la cookie compartida.
• Cabe mencionar que esta forma solo es compatible con las versiones NET Fx 4.5, 4.7 y 4.8.

¿Qué debo hacer en .NET Moderno/.NET Core?

• En .NET Core / ASP.NET Core no se necesita agregar paquetes adicionales, pero se debe configurar el middleware DataProtection (líneas 14 y 16), indicando el directorio compartido.
• Finalmente, se configura la autenticación por cookies desde la línea 19 a la 30; la parte importante aquí es el nombre de la cookie compartida, debe ser el mismo en ambas aplicaciones. En este caso se eligió “.AspNet.SharedCookie”.

Repositorio de ejemplo

Adjunto un repositorio de ejemplo con el código explicado. El repositorio cuenta con dos proyectos: “webnetfx” de .NET Framework 4.8 y “webnetcore” de .NET 10.

Repositorio de ejemplo para shared cookies :)

---

Sígueme en Linkedin para estar al tanto de mis publicaciones y novedades

Referencias

• Share authentication cookies among ASP.NET apps