A la hora de implantar una solución de federación, o de sustituir una solución heredada existente, consideremos cómo "pensar el problema de otra manera" puede mejorar las cosas.
Un cliente actual tiene una plataforma de SSO y federación "heredada" que es relativamente compleja. Se trata de una implementación de Siteminder con los componentes de federación de CA añadidos. Aunque la solución funciona, el cliente desea eliminar los costes de licencias y simplificar su infraestructura. Estamos implementando AD FS para que sirva como motor de federación. Los objetivos a largo plazo incluyen la migración del conjunto de aplicaciones SSO a SAML 2.0, y las aplicaciones serán conscientes de las reclamaciones siempre que sea posible. Si no es posible, algunas aplicaciones se convertirán a Kerberos o a la autenticación integrada de Windows.
Parte de mi filosofía arquitectónica se centra en la simplificación. La simplicidad, cuando se aplica con sensatez, es más estable y fiable, es más fácil de soportar y (debería ser) más fácil de entender.
Aunque la arquitectura de Siteminder existente presenta algunas ventajas y puntos fuertes, el cliente no estaba aprovechando el conjunto de funciones disponibles en la solución de CA. Esas funciones no eran realmente necesarias para alcanzar los objetivos de su proyecto. ¿Por qué pagar por funciones que no utilizas y que no tienes intención de utilizar nunca?
En la nueva solución, AD FS se encarga de la lógica de políticas a través de su motor de federación y las aplicaciones federadas posteriores gestionan su propia lógica de autorización (al igual que hacían con la solución heredada). Las aplicaciones sin capacidad de federación tienen un proxy inverso detrás de un filtro ISAPI de Siteminder y utilizan una simple variable de encabezado con un número de ID de empleado como valor. Esta no es una forma segura o moderna de hacer las cosas.
Pasar por el proxy y comprobar constantemente el estado de la cookie de Siteminder está muy bien, pero ¿cómo resolveremos el paso del valor del encabezado del ID de empleado? ¿Es SSL "suficiente"? No me siento cómodo con este nivel de seguridad (o la falta de ella), pero tenemos que trabajar por ahora con lo que las aplicaciones de aguas abajo de apoyo.
Una de las claves de mi solución es que no depende de AD FS: si nuestro cliente decide migrar a otro producto o subcontratar la función de proveedor de identidades a un proveedor en la nube, esta solución funcionará sin necesidad de código adicional ni modificaciones. El administrador del cliente simplemente actualiza dos líneas en un archivo de configuración y ya está listo para consumir aserciones SAML de un nuevo proveedor de identidades.
Veamos los principales elementos arquitectónicos y de diseño de esta solución:
- No utilicé WIF (Windows Identity Foundation). Aunque WIF es el núcleo del desarrollo basado en reclamaciones para aplicaciones .NET, no encajaba con los conceptos clave de mi diseño. Ya he mencionado uno: que evitamos estar atados a AD FS.
- Quería aumentar el rendimiento utilizando código compilado en lugar de ASP interpretado. Planeaba escribir la aplicación en C#, pero la quería como ensamblador. Hay otras razones para compilar el código que veremos en breve.
- El código es un manejador HTTP personalizado, en lugar de un filtro u otra interfaz. El procesamiento tiene lugar sin necesidad de archivos html o aspx ni scripts. La interfaz del gestor acepta conexiones dirigidas a un tipo de archivo virtual.
- La solución es simplemente un proveedor de servicios o "SP" en la terminología de SAML 2.0, lo que Microsoft llamaría una "parte de confianza" en el lenguaje de AD FS. Nótese que los componentes adicionales de una plataforma de federación típica no están presentes, ya que no forman parte del objetivo del diseño: estamos resolviendo un problema concreto, no intentando crear una solución de federación multicomponente. En particular, mi intención era que el diseño admitiera múltiples socios de federación de proveedores de identidad.
- Quería que la solución fuera ligera y lo más independiente posible de otros componentes. Cuando digo "ligera", por ejemplo, ¡hay que tener en cuenta que el código no utiliza ni requiere un back-end de base de datos SQL! No hace falta, como explicaré más adelante. Piensa en cómo esto puede mejorar el rendimiento: simplemente no hay que esperar a que se produzca una conexión a la base de datos, una consulta y una respuesta. Esta simplificación elimina categorías enteras de modos de fallo.
- Por supuesto, el código es extensible: si se desea otra interfaz de aplicación descendente, puede añadirse al código sin reescribir lo que ya existe.
- Aparte del requisito obvio de que el servidor del controlador HTTP sea IIS y soporte .NET 3.5 o posterior, no he vinculado el código a ningún lenguaje de aplicación de servidor web en particular: el servidor web con el que interactúa mi código SP puede utilizar VB, C# o quizás PHP, Python o cualquier otro. La solución es "agnóstica" en cuanto a la plataforma, tanto si la aplicación con la que hacemos que SAML sea compatible está en el mismo servidor IIS como si está en un servidor independiente con Weblogic o Apache.
- Como puede adivinar, no quería que la solución tuviera que residir en un único dominio de Active Directory con el IdP, ni siquiera que necesitara Active Directory. Considere que como un SP independiente no hay ningún requisito inherente de que la aplicación federada utilice un directorio. Por supuesto, una de las opciones de conexión que he añadido es una búsqueda LDAP que crea un token de contexto de usuario ASPX, ya que era necesario para una implementación.
- En relación con el punto 5, el SP se configura a través de un sencillo archivo web.config: cuanto más sencillo, mejor, era mi objetivo de diseño. Un servidor IIS con los requisitos previos presentes: .NET 3.5 o superior, una cuenta de servicio lista para asignar al App Pool, información sobre el IdP (¡o varios IdP!) puede configurarse y estar operativo en menos de 5 minutos.
- Escalabilidad. Esperaba poder crear una solución fácilmente escalable respetando los objetivos de diseño aquí descritos. Veremos los pros y los contras de mi enfoque de "simplicidad". Sin base de datos de configuración central significa un archivo de configuración para gestionar cada servidor SP añadido (cada servidor tiene un web.config), pero el sistema funcionará muy bien con sólo unos pocos servidores, y el problema de cómo mantener unos pocos archivos sincronizados se ha resuelto a fondo y debe ser bien entendido. Incluso si tuvieras una base de datos de configuración central, algunos elementos de la configuración de n-servidores todavía tienen que ser tratados en cada sistema.
Limitaciones:
Actualmente sólo se admite el SSO iniciado por IdP con el enlace POST. Esto no es realmente una gran limitación, ya que un IdP seguro que lo soporta, es el enlace SAML más comúnmente utilizado. El código puede ser actualizado para soportar SP-initiated SSO o incluso HTTP Redirect binding (la capacidad de soporte de query-string ya está presente), pero no tengo ninguna intención de soportar Artifact resolution o SOAP binding, ya que sólo añaden complejidad y no son tan comunes. En todos mis proyectos de federación, nunca he tenido a nadie que insistiera en la resolución de artefactos o que pidiera SOAP.
Notas:
El .dll tiene actualmente un modesto tamaño de 20 kb. El tiempo típico de procesamiento de la aserción SAML es de tan solo 5 ms, con una media observada de unos 20-27 ms. Estas mediciones se realizaron en varias configuraciones de máquinas virtuales, incluida la instancia "Micro" de Amazon AWS EC2. Este tiempo de procesamiento incluye el consumo completo de la aserción SAML 2.0, incluidos los pasos necesarios, como la verificación de la(s) firma(s) criptográfica(s) y toda la lógica relativa a la entrega a la aplicación posterior.
