Envio de correo desde FIM (Conector de WebServices)

Hola a todos, hoy vamos a tratar un tema radicalmente distinto a mi habitual post de PowerShell. En este caso, vamos a hablar del conector de Web Services para FIM, y cómo se puede añadir un flujo para que envíe correo. En primer lugar, y a grosso modo, hablemos de FIM:

 Brevísima introducción a FIM

Forefront Identity Manager, FIM para los amigos,  es un gestor de Identidad. Su última versión ha sido renombrada como Microsoft Identity Manager (MIM), que en el futuro recibirá nuevos artículos en este blog. La parte más importante del producto es el Synchronization Service (FIM Sync), aunque también dispone de una funcionalidad llamada FIM Portal (basado en Sharepoint) que ayuda a simplificar algunas tareas de gestión. Su función consiste en sincronizar la identidad de los usuarios a través de muy diversos entornos. Dicho así suena a que es algo muy fácil, pero en realidad, la gestión de identidad puede suponer un dolor de cabeza muy serio en cuanto tenemos más de una única fuente de datos en la que se encuentre la identidad de los usuarios.

Vamos por partes: Entendemos por identidad como la esencia que identifica de forma inequívoca a una persona. En el caso de Active Directory, la identidad de una persona coincide con su cuenta de usuario. Pero ¿Qué sucede si lo que se tiene de esa persona es una tabla en una base de datos de Recursos Humanos? En muchos casos, lo que se hace es enviar un correo electrónico con los datos de dicha persona (su identidad) al administrador de Active Directory, quien procede al alta de dicha persona. En ocasiones, se ha automatizado el proceso, de forma que dar de alta a una persona en la BBDD de Recursos Humanos automáticamente crea una cuenta en Active Directory.

Ahora bien, ¿Qué sucede si con el paso del tiempo, el usuario notifica al administrador de Active Directory que ha cambiado su domicilio, pero no lo notifica a Recursos Humanos? O bien el administrador se encarga de decirle al responsable de RRHH que hay que cambiar el domicilio, o bien… siempre cabe la posibilidad de que el domicilio se quede sin cambiar.
La situación se complica, si además hay que gestionar la identidad del usuario en más de uno o dos sistemas diferentes. Máxime si uno de los sistemas es además un sistema personalizado propio y exclusivo de la empresa.

Forefront Identity Manager entra para poner un poco de orden en todo este caos de identidad. FIM, como herramienta, posee una base de datos llamada «Metaverso», en la que va a guardar metadatos de todas las fuentes de identidad configuradas, y se encarga de poner en orden todo ello, asignando los datos correctos a la identidad (única e irrepetible) de una persona. Pero no sólo actúa de repositorio y almacén central de datos, adquiridos mediante conectores de muy diversa naturaleza. Sino que además, actúa como sincronizador, y se encarga de distribuir los cambios que se realicen a la entidad «usuario» a todos los sistemas afectados, de forma que los datos de dicho usuario Siempre estén en sincronía.

Para poder hacer esto, FIM proporciona una serie muy amplia de conectores, llamados Management Agents, que se pueden conectar a infinidad de orígenes de identidad, como puede ser Active Directory, Microsoft SQL Server, tablas en una Base de Datos, líneas en un archivo CSV…. la variedad es inmensa. Pero pese a la gran variedad de conectores disponibles, siempre queda la posibilidad de que una empresa esté usando un sistema de gestión de identidad propio… que debe ser sincronizado con otros sistemas. Un ejemplo, puede ser una aplicación personalizada de gestión de recursos humanos.

Para este tipo de sistemas, FIM proporciona herramientas que permiten la creación/desarrollo de nuevos Management Agent, ya sea el conector ECMA 2.0, o el conector basado en WebServices.

De los dos, a priori, el que parece más sencillo de usar, pero al mismo tiempo aparenta ser el más limitado, es el conector de WebServices. Pero eso es sólo en la superficie. Ya que al profundizar en él, no es tan sencillo de utilizar ni tampoco es tan limitado como parece. Así pues, y tras esta larga introducción ¿qué mejor forma de mostrar su potencia, que mostrando un pequeño snippet que nos permite enviar un correo desde FIM?

 Prerrequisitos

Para poder replicar el contenido de este post, es necesario más trabajo del habitual. La versión de FIM sobre la que se ha trabajado es FIM 2010 R2. Como requisito base, se va a necesitar un Active Directory, así que es necesario tener un laboratorio de AD con al menos un DC. También es necesario tener un Microsoft SQL Server instalado y configurado (aunque puede estar funcionando en la misma máquina donde se despliegue FIM Sync). La buena noticia, es que en ambos casos, tanto SQL Server (2008/2012) como FIM 2010R2 tienen una trial de 180 días, así que es posible desplegarlos sin preocupaciones, que nos van a durar casi 6 meses. Finalmente, y dado que se usa el conector de web services, es buena idea tener una máquina adicional con IIS en la que se despliegue un web service. Y ya puestos a pedir, también viene bien tener un Visual Studio con el que desarrollar el web service (por simplicidad), aunque es perfectamente posible implementar un web Service SOAP que se pueda usar en Apache y PHP.

Pregunta del millón: Si se va a utilizar FIM y el conector de Web Services para enviar correo, ¿realmente es necesario montar un servidor con un webservice (por muy simple que sea) para que todo esto funcione? La respuesta es sí. FIM va a comprobar que el conector tiene definido un web service y un tipo de objeto que va a leer en sus operaciones. Así que si no existen ni el objeto ni el servidor del que lo va a leer… no se va a poder crear el conector en el cliente de FIM Sync.

En definitiva, se necesita tener al menos tres máquinas virtuales en un laboratorio de AD: Domain Controller, un Servidor Web, y la máquina de FIM (que simultáneamente hospeda SQL Server). Esta configuración FIM-SQL_Server no es la aconsejada para despliegues físicos, pero en cambio, ésta es la configuración recomendada si se va a desplegar un servicio de FIM Sync en Azure

Conector de WebServices

Este conector está basado en Windows Workflow Foundation (WWF). Bueno, en un subconjunto de WWF, para ser más precisos. Esto de entrada ya parece un limitante, pero con suficientes dosis de creatividad, es posible hacer casi de todo.

Para poder trabajar con este conector, se utiliza un editor llamado «Web Service Configuration Tool«, absolutamente minimalista, pero que cumple con su cometido a la perfección. De entrada, se puede ver que hay tres secciones bien diferenciadas: Discovery, Object Types y Test Connection.

• Discovery es la sección donde se puede editar y añadir nuevos Web Services, en este caso basados en SOAP, aunque instalando una actualización también es posible usar servicios REST.
• Object Types es la sección donde se definen los objetos que se van a sincronizar con FIM. Cuando se configura, aparecen las opciones para añadir el código WWF que va a gestionar las operaciones de Full Import, Delta Import, y Export (delete-add-replace) relacionadas con ese objeto. Estos objetos, se proyectan directamente en el metaverso de FIM a la hora de crear el Management Agent, así que es seguro decir que hay total libertad a la hora de definir los Object Type.
• Finalmente, la sección Test Connection es la que vamos a usar en este post.

Obviamente, las cosas no son tan sencillas como decir «vamos a hacer un test de envío de correo» y listo. En este caso, para poder hacer el test, FIM hace comprobaciones sobre los archivos de configuración creados con la herramienta. Se fija en detalles tan insignificantes como que la herramienta se va a conectar a un Web Service SOAP existente, o que los datos que devuelve el Web Service son compatibles con un Object Type detallado previamente, etc. Por eso es necesario contar con una máquina adicional que

Cómo crear un Web Service en Visual Studio, e instalarlo en un servidor IIS adicional para que FIM pueda leerlo, es un tema aparte que merece un mini-post para detallarlo. Simplemente decir, que para que todo esto pueda funcionar con el Web Service Configuration Tool en modo SOAP, es necesario tener un web service accesible, y que haya sido configurado en la herramienta, de forma que pueda pasar las validaciones de FIM Sync. Para ello, simplemente acudimos a la sección de Discovery, y añadimos un nuevo servicio, con tipo de tipo de credencial none y con modo de seguridad none. Al fin y al cabo, es un servicio de pruebas, y no es necesario complicarse aún más con modelos de autenticación.

A continuación añadimos un objeto, para que las validaciones de FIM no se quejen y nos digan que el conector no es válido. Sumamente sencillo y rápido, que lo importante no es crear el objeto en el configurador

Ahora que ya está todo preparado (Active directory, despliegue de máquinas, servicio web…) vamos a lo importante: cómo enviar correo.

Envío de Correo: Uso de la sección Test Connection

Con todo ya preparado, ¡toca ponerse manos a la obra! Tenemos el Web Service Configuration Tool, así que toca empezar a mover componentes. Como estamos trabajando con Windows Workflow Foundation, todo va a ser bastante visual, y sobre todo, hay que tener en cuenta que el código se incrusta dentro de bloques denominados secuencias.

Lo primero: Definir las variables que necesitamos para desarrollar el proyecto.

El editor de configuración, dispone de tres secciones interesantes en la parte inferior de la ventana de edición de código: Variables, Arguments, Imports. Para el uso que importa en este artículo, sólo se va a hacer uso de la sección “Variables”, en la que definimos las variables que se van a utilizar. Es importante señalar dos apartados de esta sección: Scope que indica el ámbito de la variable, dentro de una secuencia, y Variable Type, que es donde definimos el tipo de las variables. En Variable Type, se muestra una serie de tipos predefinidos aunque, y aquí entra la magia, es posible buscar cualquier clase presente en el .NET framework para utilizarla como tipo de variable.

Establecer que las variables estén en el scope “sequence” (el top-level) es el equivalente a definirlas como variables globales que estarán disponibles para todas las secuencias que se creen dentro de la secuencia padre.

A continuación, es necesario definir la estructura de lo que es necesario para enviar un correo. Los pasos básicos. Esto lo vemos en la siguiente captura de pantalla:

Tenemos una Secuencia, que es el cuerpo principal del programa en WWF que se va a “escribir” en la sección de “Test Connection”. En esta secuencia, se añade una nueva secuencia, y se la llama “SendMail”. Una secuencia equivale conceptualmente a una función. Es una agrupación de elementos, que se puede plegar y desplegar a voluntad para ocultar sus contenidos. En este caso, la secuencia SendMail tiene tres partes: Una que es el cuerpo del Mensaje, que se define asignando un valor a una variable, otra sección que es “configurar Servidor SMTP”, y una última sección que es “Enviar Mail”. Estas secciones se despliegan a continuación para mostrar sus contenidos.

En la secuencia de “Configurar Servidor SMTP”, lo que se hace es configurar el objeto del tipo SMTPClient que se definió al principio del proceso. Para mejorar la claridad de lo que se hace, hemos renombrado las acciones del tipo “assign” para que su descripción muestre la ruta completa de variables que se está asignando. Convenientemente, las credenciales para conectar al servidor SMTP quedan oscurecidas dentro del textbox en el que están escritas, pero para que lo tengamos claro, son un objeto del tipo Net.NetworkCredentials. Para simplificar aún más, indicamos que el cuerpo del mensaje no es HTML.

A continuación, desplegamos la segunda secuencia “Enviar Mail”

 

En este caso, se establece la dirección de envío (mailMessage.From = New System.Net.MailAddress(fromMailAddress)), y aquí viene lo potente: El componente de WWF “InvokeMethod”, que permite ejecutar un método de una clase que haya sido instanciada en un objeto. En este caso, se añade la dirección a la que se quiere enviar a la lista de destinatarios. Es necesario usarlo, ya que internamente es una lista, y los correos destino se deben añadir uno a uno. Se define el Subject del mensaje, se define el Body del mensaje, y se vuelve a usar un InvokeMethod para, esta vez sí, hacer que el objeto SMTPClient (instanciado como smtpService) se encargue de enviar el correo electrónico que hemos definido.

Finalmente, si queremos que FIM se entere de que todo ha terminado con éxito, toca añadir al final de la secuencia la siguiente asignación:

Con esto, hemos definido la configuración del conector de Web Services. Pero todo esto, por sí solo, no hace absolutamente nada. Es necesario Crear un Management Agent del conector de Web Services en FIM Sync, e indicarle que use este archivo de configuración. Para ello, lo más importante es copiar el archivo de configuración a una carpeta muy concreta, de lo contrario, FIM Sync no será consciente de su existencia.

 

Finalmente, con el archivo de configuración copiado en la carpeta de Extensiones, se puede proceder a crear el Management Agent. Para ello, se abre el Synchronization Service Manager on FIM, y se acude a la sección “Management Agents”, seleccionamos “Create”, y nos encontramos con esto:

Se selecciona que el Management Agent que se desea crear es el de “Web Service (Microsoft)”, se le pone un nombre, y se pulsa “Next”, esto nos lleva a la pantalla de configuración de conexión del MA.

En esta sección, es importante elegir el proyecto del configurador del conector que hemos creado, y el Host y el puerto que hemos definido en el proyecto, así como la misma configuración en el modo de seguridad y el tipo de credencial de cliente. FIM va a validar todo esto, y en caso de que haya algún error no va a dejar que continuemos bajo ningún concepto.

Una vez  todo está validado, FIM pasa a la siguiente pantalla “Global Parameters”, en la que aparece un único checkbox disponible:

¡¡¡¡ “Test Connection” !!!! Marcando este checkbox, FIM va a ejecutar el código que hemos creado anteriormente en el apartado “Test Connection”, que existe única y específicamente para ser ejecutado en este instante. Esto es muy útil para probar partes del código del conector de Web Services, ya que se pueden ejecutar sin ningún tipo de compromiso, y en caso de que todo haya funcionado bien, lo sabremos gracias a la sección “Result = true” que añadimos al final del código. Para pruebas más complejas, es muy útil no devolver ningún valor de Result (por defecto es false), o cambiarlo a False en caso de que algún tipo de validación no se haya ejecutado como se espera.

Es la hora de la verdad: En cuanto se pulse “Next”, teniendo el checkbox marcado, FIM va a compilar el conector de Web Service, y va a ejecutar la sección de “Test Connection”. En caso de que todo salga bien, se enviará un correo electrónico a la dirección deseada, y el cuadro de diálogo para crear un Management Agent pasará a la siguiente sección “Configure Partitions and Hierarchies”. Pero todo ello ya no pertenece al ámbito de este post.

En cambio, lo que sí pertenece, es la última captura de pantalla…

Finalmente, ¡los correos han llegado a su destino!

 

Conclusión

En este artículo se ha compartido un fragmento de código para el conector de Web Services, que es muy útil a la hora de diagnosticar problemas en casos de importaciones masivas. Por ejemplo, si hay que sincronizar medio millón de usuarios, eso es un proceso que puede tomar varios días de proceso para el conector. En caso de que hubiese algún tipo de problemas, un sistema de alertas por email que indique que algo está pasando es vital para ayudar a actuar de inmediato, corrigiendo la situación que esté dando problemas en el lado servidor antes de vernos forzados a interrumpir el proceso. Cualquier interrupción de una operación de full Import puede suponer días de espera, ya que es una operación que no puede ser reiniciada.

En definitiva, una herramienta útil para desarrollos más complejos utilizando el conector de Web Services.

¡Hasta la próxima!