Selección del tipo de integración

Se puede obtener una primera aproximación sobre cómo enfocar la integración de una aplicación contestando a estas cuestiones:

• ¿Autentica contra un Controlador de Dominio que vaya a ser aprovisionado desde OIM?
• ¿La aplicación autentica contra LDAP y esta autenticación puede pasar a hacerse directamente contra el Directorio de GUIA?
• ¿La aplicación hace un uso de datos de identidades y organización que se pueda hacer a través de Web Service?
• ¿La aplicación puede ser aprovisionada desde OIM a corto plazo?

La resolución de estas cuestiones ayudan a identificar el tipo de aplicación y el modo de integración más adecuado.

Autenticación contra Controlador de Dominio aprovisionado

Este tipo de integración es adecuado para aplicaciones que autentiquen contra un Controlador de Dominio para el que se establezca un aprovisionamiento desde OIM. Las cuentas de usuario del controlador de dominio serán gestionadas desde el motor de aprovisionamiento de GUIA. De esta forma GUIA será quien controle quién accede a estas aplicaciones, sin necesidad de realizar ninguna actuación sobre las mismas. Este caso no requiere ninguna actuación desde el ámbito de la integración de aplicaciones y quedarán integradas directamente al aprovisionarse el Controlador de Dominio. Este tipo de integración no es óbice para que en fases avanzadas del proceso de implantación de GUIA se decida avanzar en otros aspectos de integración, lo cual es el objetivo al que se debe apuntar en el proceso de integración.

Autenticación contra el directorio OID

Este tipo de integración consiste en la autenticación directa de la aplicación sobre el Directorio Corporativo. Para que la integración pueda realizarse de esta manera deben darse las siguientes condiciones:

• Aplicaciones que autentiquen actualmente contra un OpenLDAP de correo:
  • Que, para autenticar contra el Directorio Corporativo, solo requieran modificar los parámetros de acceso.
  • Que se pueda modificar fácilmente el modo de acceso al directorio en caso de que este se realice actualmente de manera no autenticada.
  • Que no consuman más información del directorio que la propia búsqueda de usuarios y sus atributos.
• Aplicaciones que autentiquen contra un repositorio propio distinto de LDAP:
  • Que no requieran una migración de información al Directorio de GUIA desde un repositorio propio.
  • Que se pueda cambiar su autenticación fácilmente al Directorio de GUIA mediante protocolo LDAP.

Estas aplicaciones se integrarán en autenticación por sustitución directa de los parámetros de acceso al OpenLDAP de correo o añadiendo autenticación LDAP contra el OVD del Directorio Corporativo. Dadas sus características no requerirían ningún trabajo adicional. Para determinar de forma preliminar si la aplicación realizará autenticación directa contra el OVD mediante protocolo LDAP hay que resolver las siguientes cuestiones: Si la aplicación autentica actualmente contra un directorio LDAP:

• ¿Se ha determinado el acceso al directorio a través de OVD?
  En caso afirmativo se tiene la certeza de que la aplicación podrá autenticar a sus usuarios contra OVD y puede darse respuesta afirmativa a este bloque.
• ¿Qué tipo de directorio es?
  En este punto se requiere saber qué tipo de directorio se trata. En principio habrá más facilidad para incorporar repositorios LDAP derivados de los LDAP de correo corporativo y aquellos que sigan un modelo conocido.
• ¿Su estructura interna y atributos son compatible con la de GUIA?
  Hay que considerar en este punto si la definición de ambos directorios facilita o dificulta el paso de la aplicación de uno a otro.
  El uso de los mismos atributos implica la posibilidad de tomarlos directamente del directorio de GUIA, una vez migrados, sin necesidad de adaptar estos siempre que se emplee la misma semántica.
  Se debe emplear además la misma semántica de atributos, es decir, que su uso sea el mismo. En caso de que no fuese así no basta con redirigir la autenticación al directorio. Habría que adaptar la aplicación a la semántica adecuada. Habría entonces que evaluar esta modificación para considerar si se va a hacer autenticación directa contra el OVD. Hay que considerar también si el atributo de autenticación de los usuarios almacenado en el LDAP actual existe o existirá en GUIA. Se entiende que al revés si será pues si no la migración de identidades no sería posible.
• ¿El directorio contiene información no compatible con el Directorio de GUIA?
  En este caso no bastaría con configurar la aplicación para conectar con el OVD y sería necesario modificar la aplicación para acceder a esta información ya sea en el repositorio actual o en uno nuevo específico para la información que no sea posible migrar.
• ¿Es posible configurar la aplicación para que use distintos directorios (por ejemplo OVD y LDAP actual) y para que haga un acceso LDAP autenticado?
  Si la aplicación permite actualmente acceso a repositorios distintos por configuración esto resuelve las coyunturas planteadas en cuestiones anteriores y sería posible una integración por configuración. En caso contrario hay que tener en cuenta la posibilidad de modificar la aplicación para incluir esta opción.
  Si la aplicación no permite configurar un acceso autenticado al LDAP sería necesario modificarla para autenticar contra el OID a través del OVD. Mientras se estuviese utilizando un adaptador para OVD no sería necesario ningún cambio.

Si la aplicación autentica actualmente contra un repositorio propio distinto de LDAP:

• ¿Están o van a estar los usuarios registrados en GUIA?
  Es requisito para que estas aplicaciones autentiquen en GUIA que las identidades de los usuarios (personal con acceso a los sistemas de información de la Junta de Andalucía) estén registradas en el directorio de GUIA. Existirá un periodo de tiempo en el cual los usuarios podrá estar registrados en el directorio de GUIA y LDAP de correo, aunque finalmente sólo aparecerán registradas en el directorio de GUIA.
• ¿El atributo de autenticación de los usuarios está o va a estar en el Directorio?
  Si el atributo de autenticación de los usuarios no estuviese disponible en el repositorio existirían dos opciones: que los usuarios autentiquen con un nuevo identificador existente en GUIA o que exista un parámetro en la base de datos que permita que los usuarios sean autenticados en el directorio de GUIA empleando ellos su identificador original. Este último caso es el preferente de cara a la usabilidad de la aplicación y requiere que se mantenga el repositorio de base de datos.
• ¿Es posible mantener autenticación contra el OVD y contra la base de datos simultáneamente en caso de que no todos los usuarios vayan a estar en GUIA?
  Dependerá de la arquitectura e implementación de cada aplicación. La aplicación deberá ser capaz de acceder a dos repositorios de datos para realizar la autenticación: GUIA y su base de datos propia, teniendo precedencia la información almacenada en GUIA. De no ser posible una solución sencilla habrá que plantearse si será mejor utilizar una solución de integración basada en el aprovisionamiento.
• ¿Es posible configurar fácilmente la aplicación para que autentique contra el OVD?
  Además de la disponibilidad de las identidades, hay que considerar que el paso de autenticar contra el OVD en lugar de contra la base de datos pueda realizarse de manera sencilla en la aplicación existente. Lo ideal es que pudiera hacerse simplemente cambiando la configuración de la aplicación.

Autenticación avanzada

Este tipo de autenticación consiste en el uso, por parte de la aplicación de un módulo independiente que le permita la autenticación de sus usuarios en GUIA a través del OVD del Directorio Corporativo pasando por encima de sus sistemas previos de autenticación. Para que la integración sea de esta forma deben darse las siguientes condiciones:

• Aplicaciones que autentican tanto mediante el uso de nombre de usuario y contraseña o mediante certificado digital.
• Repositorio de identidades para autenticación distinto de openLDAP de correo.
• En todo caso debe existir una relación unívoca entre la información almacenada en el Directorio Corporativo y la información de usuarios de la aplicación. Por ejemplo, en el directorio se almacena el anagrama fiscal largo, la aplicación también lo almacena aunque los usuarios tienen su propio identificador. En este caso, durante la autenticación se incluiría el anagrama fiscal largo, de tal manera que la aplicación pueda conocer qué usuario se ha autenticado.
  Si no existiese información de la aplicación relacionada con la información del directorio, existirían ciertas alternativas. Estas alternativas deben ser estimadas y valorar si es necesario realizar el esfuerzo.
  • La aplicación ampliaría su modelo de datos para incluir la información de relación. Esta alternativa dependerá de la aplicación y del esfuerzo que supone la ampliación de su modelo de datos.
  • Ampliar el módulo de autenticación para realizar la consulta del identificador de usuario en un determinado repositorio proporcionado de la aplicación, a partir de la información del Directorio Corporativo. La aplicación deberá proporcionar el mapeo de la información de usuario de la aplicación y la del Directorio Corporativo.
  • Ampliar el esquema del Directorio Corporativo para incluir el identificador usado por la aplicación. Esta alternativa dependerá de la importancia de la aplicación y deberá ser aprobada por la dirección de proyecto.

Autorización y Uso del Directorio

En este caso la aplicación requiere consultar otra información además de la propia de identidades como por ejemplo la pertenencia de una identidad a un grupo concreto de usuarios. Es decir, los accesos al directorio no se limitan a la autenticación de usaurios sino que se consume información de este.

• ¿Trabaja la aplicación con identidades de otros usuarios distintos del principal (autenticado) o utiliza información de la estructura organizativa del organismo en su lógica de negocio?
  Aplicaciones que trabajen con información de este tipo son buenas candidatas a integrarse inicialmente mediante el uso del Directorio por servicios web y garantizar además que estos datos están actualizados.
• ¿Cómo se establecen a nivel de repositorio de identidades permisos y roles?
  Habría que averiguar si la gestión de permisos de la aplicación es compatible con la de GUIA y si, por lo tanto, es útil para ésta tomar la información de estos permisos mediante el servicio web de roles.

Aprovisionamiento

Este tipo de integración consistirá en el aprovisionamiento de datos de usuarios desde OIM a la aplicación. Las aplicaciones que se integren tendrán que adaptarse para recibir aprovisionamiento desde OIM a través de un servicio web propio así como actuar contra uno del OIM para tareas de refinamiento del aprovisionamiento recibido. La aplicación debería autenticar preferentemente a sus usuarios a través del OVD mediante protocolo LDAP.

Las aplicaciones que se integren en aprovisionamiento no tiene requisitos especiales respecto a su configuración actual relativa a repositorios de usuarios, configuración, etc. De todas manera, dado el esfuerzo necesario para la implementación e integración de los servicios mediante los que se realizarán las comunicaciones de aprovisionamiento, es aconsejable que en estas aplicaciones su gestión de usuarios sea independiente y robusta. Esto minimiza los esfuerzos necesarios para realizar la integración y produce un impacto menor en la aplicación.

• ¿Cómo se realiza la gestión de usuarios y roles/permisos de la aplicación?
  El modo en que se realiza dicha gestión y las necesidades de la aplicación respecto a la gestión de información de los usuarios son determinantes para abordar este tipo de integración. Una aplicación que no contenga información ninguna de los usuarios, por ejemplo, solo requeriría autenticación mientras que para otras aplicaciones puede ser muy conveniente estar informadas de las modificaciones en éstos.
  Por otro lado para evaluar los esfuerzos que requeriría esta integración es necesario conocer a fondo la gestión de usuarios que se hace en la aplicación.
• ¿Se puede aislar el código de gestión de usuarios en la aplicación?
  Para poder recibir aprovisionamiento de identidades es muy conveniente que la lógica de gestión de usuarios en la aplicación sea robusta y se pueda aislar fácilmente para considerarla una API práctica para incorporar los servicios requeridos.
• ¿Se puede incluir fácilmente la publicación del servicio web de aprovisionamiento?¿La tecnología de soporte a la aplicación ofrece facilidades para el despliegue de servicios web?
  Relacionado con el punto anterior está el requisito de una fácil inclusión de las modificaciones necesarias para implementar el servicio web requerido y modificar, para ello, la gestión de usuarios. Todo ello redunda necesariamente en el esfuerzo necesario para completar este tipo de integración.