Introducción a Single Sign-On – Parte I

  • Article

Que necesitamos, que tenemos

En un futuro no muy lejano, los desarrolladores contaran con un modelo que facilitara el intercambio de credenciales mediante protocolos estándares, facilitando la integración entre plataformas; hoy en día existe una cantidad de tecnologías emergentes que están trabajando para lograr este objetivo, incluidas la especificación de WS-Security. En caso que no lo sepan esta especificación (en la que trabajan VeriSign, Microsoft, e IBM) define un conjunto de extensiones SOAP para intercambiar mensajes seguros . Junto con otras especificaciones emergentes de Web service (ws_* ) forman la base para construir servicios Web independientes, federados e ínter-operables que junto con futuras herramientas podrían (de hecho creo que realmente lo harán) ser la piedra angular para construir Soluciones basadas en estándares para el manejo de credenciales. Mientras tanto, necesitamos un middleware para ayudarnos a resolver estos desafíos.

El termino single sign-on, esta asociado generalmente con distintas categorías de autenticación, en las que se incluyen la autenticación simple, autenticación Web y autenticación de tipo EAI (Enterprise Application Integration), nos centraremos específicamente en esta ultima ya que estos servicios son bastante mas complejos e involucran la integración de varios sistemas heterogéneos que incluso, a veces residen en distintas plataformas.

Herramientas provistas por BizTalk Server 2004…

BizTalk's Enterprise Single Sign-On (SSO) es un servicio individual que permite asociar cuentas de usuarios de Windows a otras cuentas de usuarios de Windows o cuentas que no sean de usuarios de Windows. Estas cuentas están asociadas (o mapeadas) por aplicación, con el fin de poder ser utilizadas para acceder a aplicaciones utilizando credenciales diferentes a las del usuario final. Estas credenciales se encriptan y almacenan en una base de datos para luego ser recuperadas para acceder a la aplicación en cuestión y pueden ser enviadas utilizando una amplia variedad de protocolos; actualmente BizTalk Server 2004 SSO soporta el mapeo de credenciales y la recuperación de las mismas sobre HTTP y SOAP. De esta forma, luego que el usuario esta autenticado en Windows, no necesita ingresar otras credenciales para acceder a los diferentes sistemas de back-end. Como mencione anteriormente, SSO de BizTalk Server 2004 es un servicio independiente y puede integrarse fácilmente con otras aplicaciones utilizando los adaptadores, incluso es posible construir adaptadores personalizados (utilizando BizTalk Server 2004 Adapter framework)

Escenarios comunes

Existen múltiples escenarios de que debemos tener en cuenta cuando se diseñamos este tipo de Soluciones; actualmente BizTalk Server 2004 soporta SSO Iniciado en Windows y Repositorio de configuración (Windows Initiated SSO, Configuration Store respectivamente según la documentación en ingles). A continuación describiré brevemente cada escenario:

SSO iniciado en Windows

En este escenario, el servicio de SSO se utiliza para asociar credenciales desde una aplicación Windows a una aplicación que no es Windows. El siguiente grafico muestra la secuencia clásica de pasos para este escenario (ver imagen):

  1. Un usuario, intenta ejecutar una aplicación que muestra información de diferentes sistemas de back-end. Esta aplicación utiliza Windows Integrated para autorizar al usuario.
  2. La petición es recibida por un adaptador compatible con SSO (recordemos que puede ser HTTP/HTTPs/SOAP). El adaptador realiza una solicitud a SSO para obtener un ticket encriptado basado en las credenciales de Windows.
  3. SSO genera el ticket, le agrega información en la cabecera (headers) del mensaje y lo devuelve al adaptador.
  4. El mensaje se envía a la base de datos MessageBox.
  5. El mensaje es procesado (por ejemplo) por una orquestación.
  6. El mensaje se procesado por el Send Adapter, (también debe ser "SSO-compatible" ) para que ejecute una nueva solicitud al sistema SSO con el ticket encriptado (7). De esta forma se valida, se obtienen las credenciales para la aplicación de back-end asociada (affiliate application) y se envía el mensaje (8).

Para ejecutar este escenario, el administrador define las entidades lógicas que representan las aplicaciones o sistemas de back-end; a estas aplicaciones o sistemas se las denomina afíliate application. El administrador define las asociaciones entre las credenciales para cada affiliate application. Este esquema presenta en un esquema de nivel superior cual es el proceso en general. Entraremos en detalle acerca de los procesos relacionados con la emisión del ticket, su cancelación y la arquitectura subyacente de SSO en el artículo posterior.

Repositorio de configuración

Como mencionamos, SSO nos permite almacenar información que permite asociar credenciales, pero además podemos almacenar información de configuración de las aplicaciones asociadas, en forma segura. En este escenario, los datos están asociados con la configuración de las aplicaciones en ves de credenciales de usuario. En este escenario, los datos se almacenan en un tipo distinto de affiliate application, denominada config store. El concepto general es el mismo del escenario anterior, con todos los datos encriptados y almacenados en la base de datos de configuración, la única diferencia es que en ves de asociarse por medio de un UserId, se asocia mediante un UniqueID. Cuando una aplicación llama a los servicios de SSO para buscar esta información los servicios de SSO devuelven este identificador único.

Escenarios no soportados

La siguiente lista de servicios y escenarios no están soportados por esta versión de BizTalk Server 2004 SSO:

  • Single sign-on desde un sistema no-Windows a Windows.
  • Sincronización de contraseñas de Windows.
  • Sincronización de contraseñas de sistemas que no sean Windows.
  • Sincronización completa de contraseñas

Autor: Christian Carnero

Este mensaje se proporciona "como está" sin garantías de ninguna clase, y no otorga ningún derecho