Creo que es apropiado encarar este post desde una de las grandes problemáticas que se esta empezando a dar en la actualidad:
En la medida en que los sistemas de las organizaciones se van multiplicando con el paso del tiempo, la administración de identidades (información de usuarios) entre dichos sistemas se va complejizando volviéndose un trabajo arduo, tedioso y en muchos casos incontrolable. Es importante tener en cuenta los riesgos de seguridad que pueden tener lugar en escenarios de este tipo. Para ilustrar un poco esto, les daré un ejemplo real en unas de las empresas en la cual trabajé:
”La organización contaba con una gran variedad de sistemas y tecnologías como Microsoft Sharepoint, SAP, Oracle, Biztalk, etc. Nos informan que un directivo de alto rango había sido despedido, por lo que tenía que empezar un proceso de baja de usuario en todos los sistemas en los que estaba registrado, con todo lo que esto significa, ya que había varias instancias de este usuario en cada una de las aplicaciones en las que había tenido actividad. Lo interesante de esta anécdota es que el informe lo recibimos a los últimos minutos de finalizar la jornada laboral un día Viernes, por lo que tuvimos que poner leña al fuego y tratar de ubicar a todos los responsables de cada departamento para pedir la baja de este usuario, si es que aún no se habían retirado. Recuerdo que fue un día largo y nos trajo muchos dolores de cabeza.”
Forefront Identity Manager (FIM) es una plataforma de administración de identidades, credenciales y políticas de acceso de Microsoft, destinada a cubrir este tipo de dificultades.
Voy a desarrollar brevemente y lo más claro posible, qué es Forefront Identity Manager para los que no lo conocen. Y como final y puntapié inicial del próximo post, introducirnos a los Management Agents de FIM.
Introducción
Para comenzar, vamos a ver dos imágenes interesantes. La primera es bastante intuitiva y nos va a servir para armar un mapa mental sobre el concepto de FIM:
Como pueden ver Forefront Identity Manager 2010, posee la capacidad de integrar identidades de diferentes aplicaciones y datasources, centralizando y sincronizando información. A partir de este sistema centralizado, los administradores pueden definir políticas, manejar credenciales, usuarios y grupos de modo que estos cambios puedan impactar en las aplicaciones o data sources conectados a FIM. Una de las cosas más importantes que nos provee FIM es la posibilidad de personalizar los conectores, pudiendo estos, ser desarrollados en Visual Studio, lo que implica que podamos hacer extensible el manejo y sincronización de los datos hacia cualquier sistema que disponga de una interfaz de comunicación.
En FIM 2010 Disponemos de un Portal basado en Sharepoint y la consola de Sincronización, desde donde es posible visualizar y administrar todas estas operaciones, como las Reglas de Sincronización, Workflows, Mapeos, etc.
Una vez conceptualizado esto, podemos pasar a la siguiente imagen para observar un poco mas en detalle los componentes de la arquitectura de FIM:
Para el tema en desarrollo nos vamos a concentrar en los siguientes componentes principales: el Portal (2), los Adapters (10), estos serán nuestros Management Agents (MA), el FIMSync (11), el cual es el corazón de esta plataforma que como pueden ver es el encargado de integrar a los Identity Stores y por último el FIM Service que involucra los componentes 5,6,7 y 8.
Para mas información sobre los demás componentes, les dejo el link de msdn http://msdn.microsoft.com/en-us/library/windows/desktop/ff182370.aspx
Como trabajan estos?
Como mencioné antes, FIM dispone de la capacidad de conectar múltiples Identity Stores o DataSources por medio de los MAs. Cada MA que se crea para alguna conexión, dispone de una base de datos propia llamada ConnectorSpace (esta base es creada por FIM cada vez que se crea un MA).
Supongamos que una de las aplicaciones conectadas a FIM realiza alguna modificación en los datos de un usuario, como podría ser la dirección de mail, el teléfono o el lugar de trabajo. El MA de este sistema importará los datos modificados al ConnectorSpace. Luego se ejecuta una sincronización que creará, o actualizara en caso de que existan, estos datos en una base única llamada Metaverse, luego, mediante, una Regla de Sincronización (Synchronization Rule), se detectan que DataSources utilizan estos datos de modo de importarlos a los ConnectorSpaces correspondientes, para finalmente ser exportados a dichos DataSources. De este modo se mantiene la consistencia de datos referente a usuarios o grupos en todos los sistemas que estén conectados y vinculados mediante las Reglas de Sincronización.
Les dejo la documentación en donde puede ver con mayor detalle todos los aspectos de la sincronización:
http://msdn.microsoft.com/en-us/library/windows/desktop/ms698364.aspx
Para nuestro objetivo nos vamos a enfocar sobre los MAs (Management Agents). Los MA son componentes (dlls), desarrollados en Visual Studio .Net, que residen en el servidor de Sincronización, encargados de realizar las operaciones de importación y exportación de los datos.
Es claro en la imagen, la interfaz que brindan estos MA para la integración de aplicaciones.
En FIM disponemos de una basta lista de MA para crear y configurar, como por ejemplo para integrar SQL, AD, SAP, etc. Pero que pasa si ninguno de estos cumple con los requerimientos del cliente?, o si nuestro MA tiene que realizar algún proceso en particular?, y aquí ya nos vamos perfilando al tema troncal de este post, tenemos la posibilidad de desarrollar nuestros propios Extensible Connectivity Management Agent (ECMA) a partir una API (Microsoft.MetadirectoryServices.dll) que nos provee FIMSynchronizationService.
En el próximo post estaremos viendo como desarrollar e implementar un Management Agent personalizado para integrar un sistema de facturación a través de sus WebServices.