BizTalk Server 2004: Introducción al Enterprise Single Sign-On

Introducción

Este corto artículo presenta una introducción a uno de las facilidades más importantes, pero tal vez menos visibles desde el exterior, que componen a BizTalk Server 2004: El Servicio de Enterprise Single Sign-on (SSO). Esta introducción se presenta desde el punto de vista de funcionalidad ofrecida y de la arquitectura del servicio de SSO.

Mucha parte de este artículo aplica también para la implementación de SSO disponible con Host Integration Server 2004.

Qué es el SSO?

El Enterprise Single Sign-on es un servicio que permite el mapeo de credenciales de seguridad entre Windows y otros sistemas heterogéneos, permitiendo que los usuarios puedan acceder diferentes aplicaciones con un solo conjunto de credenciales, particularmente en escenarios de Enterprise Application Integration (EAI).

El SSO funciona con base a la definición de mapeos entre diferentes entornos que manejan diferentes mecanismos de seguridad, de forma tal que los aplicativos de EAI puedan hasta cierto punto "fluir" las credenciales de seguridad a través de toda la infraestructura tecnológica de la organización, sin importar que diferentes sistemas utilicen diferentes conjuntos de credenciales de seguridad.

Un ejemplo de un escenario donde el SSO puede resultar valioso es el siguiente:

La compañía Contoso usa el Directorio Activo de Windows como su sistema primario de autenticación de usuarios. Sin embargo, todos los usuarios requieren adicionalmente de acceso a la instalación del ERP de la compañía, pero este no está integrado con AD, sino que maneja sus propias listas de usuarios. Adicionalmente, los nombres de los usuarios no son iguales entre AD y el ERP.

Contoso quiere implementar un proceso de negocio automatizado en la que un usuario Pepe envía una solicitud que es recibida por BizTalk Server, que ejecuta una orquestación. Dicha orquestación debe, en un momento dado, ejecutar una tarea en el ERP, pero debe hacerlo autenticándose frente a dicho sistema como si fuera Pepe mismo quien realizó la operación, usando su nombre de usuario correspondiente en el ERP (Usuario PepeERP).

Este es un caso protópico donde la funcionalidad de SSO podría usarse para permitir a BizTalk Server mapear las credenciales de AD del usuario Z al nombre de usuario y password correspondientes en el ERP, permitiendo que BizTalk pueda así autenticarse con las credenciales correctas frente al mismo.

SSO y MIIS

Una pregunta que puede surgir frente a SSO es cual es su relación y sus diferencias con el Microsoft Identity Integration Server 2003 (MIIS), otro de los productos de servidores de Microsoft.

Aunque en primera instancia ambos productos podrían parecer similares, realmente se enfocan a necesidades diferentes del tema de integración de identidades. El problema que realmente resuelve MIIS en este punto es el de mantener sincronizadas las diferentes identidades que se han definido en diferentes sistemas de autenticación; es decir, que cuando se crea una nueva identidad en Windows se asegure que se cree en otros sistemas asociados, que cuando se modifique o se cambie el password de una identidad, se repliquen dichos cambios a los demás sistemas, etc. MIIS trata es de disminuir el costo administrativo y operacional de tener múltiples aplicativos y sistemas operativos que manejan listas de usuarios diferentes.

SSO por el otro lado, intenta es proporcionar una infraestructura para simular un login único para el usuario corporativo frente a una plataforma tecnológica heterogónea, dentro del ambiente de aplicativos de integración.

Desde este punto de vista, realmente podría decirse que MIIS y SSO son productos complementarios. Sin embargo, hasta el momento Microsoft no ha anunciado ninguna facilidad o herramienta que permita integrar ambos aplicativos.

Arquitectura Básica

La arquitectura básica del Enterprise Single Sign-on es compuesta por 5 módulos principales:

Mapping Subservice: Se encarga de mapear entre dos conjuntos de credenciales diferentes
Lookup Subservice: Se encarga de hacer las consultas sobre las credenciales almacenadas en el SSO
Administration Subservice: Permite administrar el servicio de SSO y las credenciales allí almacenados
Secret Subservice: Es quien se encarga de controlar la encripción de credenciales y generación de tickets de autenticación
Credentials Store: Es una base de datos de SQL Server que almacena las credenciales y los mapeos entre los mismos, con la información apropiadamente encriptada.

La arquitectura del SSO es una arquitectura esencialmente distribuida, compuesta por un Master Secret Server (único en la estructura del dominio de SSO), un conjunto de uno o más Single Sign-on Servers, y el Credential Store (una DB de SQL Server). La diferencia entre el MSS y el SSO es que solo el MSS corre el Secret Subservice. En una arquitectura pequeña, el Master Secret Server y el SSO Server pueden ser uno solo.

Lo que hasta aquí probablemente no es claro es cual es la importancia del Secret Subservice, y porque es el elemento diferenciador entre ambas clases de servidores.

El Credentials Store de SSO es no solo responsable de almacenar la configuración del SSO misma, sino que es además responsable de almacenar los diferentes usuarios y grupos asociados a cada aplicación o sistema contra el que se desea mapear credenciales. Como estos mapeos pueden incluir tanto nombres de usuarios como de grupos, y adicionalmente contraseñas u otros tokens de autenticación (conocidos como "secretos"), es crítico que la información allí almacenada este completamente encriptada para que este segura.

Este precisamente es el papel del Master Secret Server (MSS). Lo que tiene el MSS que lo diferencia de los demás servidores en la infraestructura de SSO es precisamente la clave primaria con que se encriptan los contenidos en el Credentials Store; el MSS es el único servidor autorizado en la infraestructura para encriptar los datos que se van a almacenar allí.

Los demás servidores en la infraestructura solo pueden acceder el Credentials Store para leer de allí las credenciales almacenadas, ya que solo pueden realizar la desencripción de sus contenidos (solo conocen la clave de decodificación).

Ya aquí se pueden visualizar varios elementos claves para que esta arquitectura sea realmente funcional. El punto quizá más importante es que la clave maestra debe mantenerse segura a toda costa, por varias razones:

Si llegara a perderse, se perderían así mismo todos los datos almacenados en el Credentials Store, ya que no sería posible decriptarlos. Por esto es crítico que una vez establecida la clave maestra, se resguarde esta apropiadamente en un medio externo y se almacene dicho resguardo en un sitio físicamente seguro.
Debe ser posible cambiar periódicamente la clave maestra de encripción, lo cual puede ser necesario, por ejemplo, en caso que la clave actual fuera comprometida (ej: se robaron el resguardo). Cambiar la clave maestra implica, en primera instancia, re-encriptar toda la información almacenada en el Credentials Store, lo cual es función de las herramientas administrativas de SSO y función únicamente realizable por el Master Secret Server.

La segunda de estas razones es clave para entender el segundo requerimiento de esta arquitectura: Si cambia la clave maestra, manejada por el Master Secret Server, este cambio debe notificarse a los demás servidores en la infraestructura de SSO; en caso contrario estos no podrían acceder la información de mapeos almacenada y la estructura colapsaría.

Para resolver este detalle, el Enteprise Single Sign-on tiene un mecanismo interno de replicación de esta información, que se hace en forma automática cada 30 segundos sobre protocolos de RPC seguros (canales encriptados).

El tercer punto crítico de esta arquitectura es que aunque el Master Secret Server es crítico para la administración y encripción de la información en el Credentials Store, no es crítico para la operación de la infraestructura de SSO en tiempo de ejecución. Es decir, que si por alguna razón el Master Secret Server saliera de línea, la infraestructura restante de SSO seguiría operando pues tendría acceso al Credentials Store (siempre y cuando esta base de datos de SQL Server no está desplegada en la misma maquina que el MSS) y podría seguir accediendo y desencriptando los mapeos allí almacenados, que es la operación más común en una infraestructura de SSO.

Aplicaciones Afiliadas

Dentro de una estructura de SSO, aparece el concepto de Aplicación Afiliada. Una aplicación afiliada es definida por el administrador del SSO como una entidad lógica que representa un sistema o aplicación que va a hacer uso del SSO para aceptar conexiones o conectarse a otros sistemas.

Cada Aplicación Afiliada tiene uno o más mapeos de credenciales, como por ejemplo mapear entre usuarios del Directorio Activo y cuentas en un Mainframe.

Normalmente, cuando se configura una Aplicación Afiliada, se definen las siguientes propiedades básicas:

Propiedad	Descripción
Nombre	Nombre asignado a la aplicación. Ej: SAP
Descripción	Descripción de la aplicación
Contacto	Dirección EMail del contacto administrativo para esta aplicación
Administrador	Se designa un usuario del dominio para administrar la configuración de esta aplicación
Usuarios	Usuarios del directorio activo que pueden acceder esta aplicación. Para esto se define un grupo del directorio activo que representará los usuarios que tendrán acceso a esta aplicación afiliada (es decir, acceso a los mapeos definidos en la aplicación).
Banderas	Conjunto de banderas de control de la aplicación.

Un punto crítico al diseñar la Aplicación Afiliada son los valores a asignar a las propiedades Group Application y Configuration Store Application.

La propiedad Group Application indica que va a usar Grupos para el mapeo de credenciales. En caso contrario, usa credenciales de usuarios individuales. En una aplicación con Group Application = falso, un usuario del directorio activo se mapea a otra cuenta de usuario individual de la aplicación afiliada (es decir, el mapeo es normalmente 1 a 1). En una aplicación con Group Application = verdadero, todos los usuarios de un grupo de Windows se mapean a un solo usuario en la aplicación afiliada (es decir, el mapeo es muchos a uno).

La propiedad Configuration Store Application se fija a verdadero, entonces esta Aplicación Afiliada se usará para guardar en forma segura información de configuración. No es una opción muy común, pero un ejemplo de esto es que BizTalk Server utiliza aplicaciones de este tipo para almacenar configuración de los puertos de envío y recepción

Ventajas y Desventajas del SSO

El uso del SSO tiene varias ventajas y desventajas básicas que son importantes a tener en cuenta a la hora de decidir si usar o no la funcionalidad provista por el SSO.

La ventaja más importante es que es una infraestructura ya provista por BizTalk y HIS mismos, con lo que tenemos la seguridad de que es una infraestructura robusta, escalable y segura; probablemente más de lo que podría desarrollarse a mano para casos puntuales en cada proyecto. Adicionalmente, hay buena integración con ambos productos, por lo que existen facilidades en los mismos para tomar ventaja del SSO fácilmente sin requerir de mucho desarrollo adicional (quizá en un artículo más adelante veremos como hacer uso de estos mecanismos).

Quizá la desventaja más grande en el uso del SSO es que la documentación es relativamente poca, y es algo confusa. Adicionalmente, actualmente el servicio de Enterprise Single Sign-on cuenta con muy pocas herramientas administrativas, y estas no son precisamente muy fáciles de usar o intuitivas (consisten solamente de un par de herramientas de línea de comando que toman archivos XML como entrada). Finalmente, actualmente el implementar una infraestructura de SSO puede ser administrativamente costoso, puesto que es necesario hacer las labores de sincronización de las cuentas de usuarios entre los sistemas manualmente (es decir, actualizar los mapeos de SSO cada vez que hay cambios en las cuentas o contraseñas).

Conclusión

Con esto concluye esta corta introducción al algo misterioso mundo del servicio de Enterprise Single Sign-on, parte de la nueva generación de productos de Integración de Microsoft. Espero que con esto puedan entender más claramente cual es el rol de SSO dentro de la arquitectura de estos productos, y los posibles beneficios que puede tener en la implementación de soluciones de EAI.