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 protot�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.