Solución para la integración de aplicaciones a través de OVD

Se expone una propuesta que, aprovechando la funcionalidad que ofrece el producto OVD (Oracle Virtual Directory), facilite la integración de las aplicaciones en GUIA.

Consideraciones iniciales

La JdA cuenta actualmente con un sistema encargado de la gestión de las cuentas de correo. Está formado por una serie de sistemas entre los que se encuentra un directorio central, basado en OpenLDAP, que se replica en directorios distribuidos en los organismos. Así, en la estructura de árbol del directorio central existe una entrada por cada organismo de la que cuelgan todas las entradas de las identidades de ese organismo de forma que, en la replicación en un organismo, sólo se distribuyen sus identidades.



Es común que los organismos utilicen estos repositorios como puntos de autenticación de sus aplicaciones validando, a través del protocolo LDAP, las credenciales de los usuarios. Cada entrada de usuario no se limita a contener el identificador (en este caso se trata del atributo UID) y la password, sino que puede contener otra información que puede ser de utilidad para las aplicaciones (nombre, apellidos, NIF/NIE, etc.).

A su vez el sistema GUIA incluye otro sistema basado en el producto OID (Oracle Internet Directory) que ofrece un interfaz LDAP y que servirá, entre otras cosas, como repositorio de las identidades integradas en el sistema1. Al igual que en el caso del OpenLDAP de correo define una arquitectura distribuida con un Nodo Central que se replica en los Nodos Locales de los organismos, pero al contrario que este, todas las identidades cuelgan de una rama única que se replica en todos los organismos. Además cada organismo contará con una rama propia con información corporativa que podrá explotar (grupos organizativos, etc.).



Evidentemente la sintaxis de los atributos utilizados para las identidades en OpenLDAP y OID difieren. Así mientras que en el DN del OpenLDAP se incluye el UID, en el caso de OID se ha utilizado el CN, que almacena un autonumérico único para cada entrada. Del mismo modo aún coincidiendo algunos atributos la semántica utilizada en uno u otro sistema puede ser distinta.

Uno de los objetivos principales del sistema GUIA es que sean estos repositorios OID los puntos únicos que utilicen las aplicaciones para la autenticación y autorización, de forma que el OpenLDAP de correo se limite a ser repositorio exclusivo para la gestión de las cuentas de correo de la JdA. Sin embargo, y por razones de operatividad, el modelo de implantación del sistema GUIA se plantea como un proceso gradual en el que las identidades se integrarán paulatinamente. De esta forma existirá un periodo de transición en el que no todas las identidades estén integradas en el Sistema GUIA y, por lo tanto, no se podrá prescindir del OpenLDAP de Correo como punto de autenticación.

En este contexto hay que mencionar que, otro de los objetivos de GUIA, es el aprovisionamiento del Sistema de Correo. Sin entrar en detalles, y a lo que al objetivo de este documento aplica, implicará:

• Toda identidad integrada en el sistema GUIA tendrá su correspondencia en el Sistema de Correo, por lo tanto, tendrá una entrada en el OpenLDAP.
• Existirá una sincronización entre los atributos de las identidades en GUIA y su correspondencia en el Sistema de Correo.

De lo anterior se puede concluir que, durante la fase de transición, habrá aplicaciones cuyas identidades no se encuentren en su totalidad integradas dentro de GUIA. Por ello se plantea la utilización del producto OVD (Oracle Virtual Directory) para facilitar la integración de aplicaciones durante este periodo de transición2.

Como última anotación de este apartado de consideraciones iniciales hay que indicar que tanto cada uno de los organismos como el Nodo Central cuenta con OVD.

____________________________________________________________________________________________________________________________________

(1) En el documento "Clasificación de Atributos de OID" se entra en detalle sobre la estructura del directorio así como de los atributos que incluirá cada entrada en el mismo.

(2) El producto OVD se utilizará no sólo con este objetivo sino que también se aprovecharán otras de sus características.

Propuesta

Como ya se ha descrito anteriormente la transición se debe abordar a un nivel de aplicación, puesto que para un mismo organismo pueden convivir aplicaciones cuyos usuarios se encuentren todos en GUIA y otras en las que no. Por lo tanto, y para describir la propuesta de utilización del OVD, resulta conveniente realizar una distinción en función de la naturaleza de las aplicaciones:

1. Aplicaciones existentes. Son aquellas aplicaciones que se encuentran actualmente en producción y que están utilizando el OpenLDAP como repositorio.
2. Aplicaciones de nuevo desarrollo (o aplicaciones existentes que vayan a migrar a GUIA). Son aplicaciones que, o bien se encuentran en fase de desarrollo o bien desean migrar hacia una integración en GUIA.

Fase de transición

La propuesta que se realiza para la fase de transición es la siguiente:

• La estructura de directorio que verán las aplicaciones será la de OpenLDAP.
  
• Las identidades que no estén presentes en GUIA sólo mostrarán los atributos propios de OpenLDAP.
• Las identidades que estén presentes en GUIA, además de los atributos de OpenLDAP incluirán los atributos de GUIA con la sintaxis de nombrado GUIA_nombreAtributo. Por ejemplo: GUIA_numdoc.

Ventajas:

• Las aplicaciones existentes que estén accediendo a OpenLDAP no requerirían modificación si no quieren explotar ninguna información de GUIA.
• A medida que se vayan incorporando las identidades en GUIA estas mostrarían los atributos propios de este sistema.
• Permite un modelo de convivencia entre aplicaciones existentes y aplicaciones nuevas: ambas utilizarían el mismo baseDN de acceso al directorio.
• Gracias al aprovisionamiento se aportaría el valor añadido a las aplicaciones de la calidad de los datos debida a la gestión realizada desde el Sistema GUIA.

Desventajas:

• Esta propuesta no permite realizar búsquedas sobre atributos de GUIA. Por ejemplo, una búsqueda con filtro "(GUIA_numdoc=12345678X)" no devolvería ningún resultado aun existiendo una entrada en OID con el numdoc=12345678X. Igual resultado se obtendría con una consulta con filtro "(numdoc=12345678X)".
• Sería inviable explotar los grupos organizativos y de trabajo con la semántica que proporciona GUIA (al no estar todas las identidades en GUIA no puede poblarse un grupo de trabajo con una identidad que esté presente únicamente en OpenLDAP).
• Esta propuesta exigiría a las aplicaciones nuevas trabajar con atributos de GUIA con una nomenclatura ficticia con lo que migrar a una foto final implicaría necesariamente nuevos desarrollos.

Por las desventajas anteriores se aconseja que las aplicaciones nuevas se planteen con un escenario de foto final.

El esquema que se seguirá será el siguiente:

Proporciona:

• Todas las identidades disponibles actualmente en OpenLDAP respetando su sintaxis.
• Si la identidad se encuentra migrada en OID, se facilitará los atributos propios de la entrada en OpenLDAP, mas los atributos de OID, renombrados con el prefijo GUIA_. Por ejemplo, GUIA_NUMDOC.

Ejemplo de entrada resultante de consultar los atributos de una identidad contenida en esta situación.

En el caso de no encontrarse la identidad en OID, no se podrá llevar a cabo relación, por lo que los atributos de GUIA, no se mostrarían.

Acceso de las aplicaciones al OVD

Debido a que durante el estado de transición únicamente se explotará información referente a las identidades (autenticación y consulta), la configuración a llevar a cabo en una aplicación que se encuentre en esta situación sería la siguiente:

• Establecer IP/PUERTO del OVD para lanzar las peticiones Ldap.
• Definir la rama base de acceso a: o=juntadeandalucia,c=es
  Donde rama de empleados= o=organismoOLDAP,o=empleados,o=juntadeandalucia,c=es. Sobre esta rama se llevarán a cabo todas las autenticaciones y búsquedas referentes a las identidades. En ella se encontrarán las identidades que tendrán como atributos los propios de OpenLDAP, más aquellos resultantes del JOIN con las identidades de OID. Ej: o=cjap,o=empleados,o=juntadeandalucia,c=es

Dificultades

Búsquedas por atributos físicos sobre OpenLDAP Esta solución conlleva una problemática sobre la búsqueda de identidades en el directorio. El filtro de mapeo se aplica al resultado de las salidas de las peticiones. Por lo tanto, y a pesar de que las identidades devueltas incluyan atributos “ficticios” (p.e. GUIA_numdoc), NO SE PUEDEN REALIZAR BÚSQUEDAS POR ESTOS ATRIBUTOS, sino únicamente por los atributos físicos. Por ejemplo, una búsqueda con filtro (GUIA_numdoc=12345678X) no devolvería ningún resultado aun existiendo una entrada en OID con el numdoc=12345678X. Igual resultado se obtendría con una consulta con filtro (numdoc=12345678X).

Falta de coherencia entre distribución de organismos Actualmente en OpenLDAP hay determinados organismos que no se encuentran contemplados en OID, por lo que la relación OID-OpenLDAP, en cuanto a organismos no se va a dar al 100%. Hay que tener en cuenta estos casos a la hora de autenticar o restringir el acceso a los usuarios a las aplicaciones. Por ejemplo:

Duplicidad de atributos. Debido a que tanto OID, como OpenLDAP, se basan en un estándar LDAP, ambos van a coincidir en nomenclatura de atributos, siempre y cuando no sea de objectclass propios. La visión que ofrece la solución de OVD basado en Join, es crear atributos multievaluados. Por solucionar esta problemática, y como se ha mencionado anteriormente, se ha optado por proporcionar los atributos de OID con un prefijo por delante que identifique que el atributo proviene de GUIA. La siguiente imagen, relaciona una identidad que se encuentra tanto en OpenLDAP, como en OID, por el uid. Como se puede observar, existen atributos (sombreados en rojo), que se duplican, por lo que deberán tener un tratamiento especial a la hora de resolverlos.

A continuación se muestra la misma identidad pero como resultado de consultar a la solución de OVD con el JOIN. Si ejecutamos la solución propuesta una identidad que se encontrara en ambos directorios, quedaría de la siguiente forma:

Como se hizo referencia anteriormente, el filtro de mapeo se aplica al resultado de las salidas de las peticiones. Por lo tanto, y a pesar de que las identidades devueltas incluyan atributos “ficticios”, NO SE PUEDEN REALIZAR BÚSQUEDAS POR ESTOS ATRIBUTOS, sino únicamente por los atributos físicos. Por ejemplo, una búsqueda filtrada por un valor de GUIA_sn no devolvería ningún resultado puesto que las identidades en OpenLDAP no incluyen este atributo.

Fase final

Una vez que todos los usuarios de una aplicación hayan sido integrados en GUIA esta podrá pasar a un modelo de fase final. Esta fase está caracterizada porque ya no sería necesario utilizar el OpenLDAP como repositorio de autenticación. En este caso se propone que las aplicaciones apunten a una nueva rama publicada por el OVD, dc=juntadeandalucia,dc=es, que accedería al OID.

De esta forma:

• La estructura de directorio que verán las aplicaciones será la de OID.
  
• Los atributos de las identidades devueltas tendrán la sintaxis de GUIA.
• Se creará una rama virtual, o=personasOLD3,o=identidades,o=comun, dc=juntadeandalucia,dc=es, pensada para aquellas aplicaciones existentes que estén utilizando OpenLDAP. Esta rama proporcionará una nomenclatura de atributos similar a la de OpenLDAP mediante transformación de los atributos que se extraen de OID. Para ello se utilizará un filtro de mapeo similar al descrito en la fase de transición. Esta rama debe ser una situación temporal a extinguir.

Ventajas:

• La calidad de la información de las identidades está controlada por GUIA.
• Se pueden explotar los grupos organizativos y de trabajo con la semántica que proporciona GUIA.
• Se permite autenticar con diferentes identificadores.
• Ofrece una alternativa a aplicaciones existentes que estén utilizando OpenLDAP para tareas básicas (autenticación) sin que necesiten refactorización.

Desventajas:

• En la rama creada para aquellas aplicaciones que utilizan sintaxis OpenLDAP se utiliza un filtro de mapeo que se aplica al resultado de las salidas de las peticiones. Por lo tanto, y a pesar de que las identidades devueltas incluyan atributos “ficticios”, NO SE PUEDEN REALIZAR BÚSQUEDAS POR ESTOS ATRIBUTOS, sino únicamente por los atributos físicos del OID. Por ejemplo, una búsqueda filtrada por un valor de jaDNI no devolvería ningún resultado puesto que las identidades en OID no incluyen este atributo.
• Actualmente, las aplicaciones que utilizan OpenLDAP y gracias a su estructura, pueden definir que sólo autentiquen identidades de SADESI con sólo configurar la base de búsqueda en o=sadesi, o=empleados, o=juntadeandalucia, c=es. Con este modelo de solución no sería viable en los casos de organismos no contemplados por GUIA. No obstante sí sería posible realizar este filtrado utilizando las visibilidades reducidas basadas en permisos sobre las cuentas de servicio de acceso.
• Posible pérdida de la calidad del dato. Para proporcionar las identidades en sintaxis OpenLDAP, se llevará a cabo un mapeo a través de Python en OVD, que será el encargado de facilitar los atributos en este formato. Debido a que los directorios almacenan la información con distinta semántica, al formar el valor de los atributos puede darse una pérdida en la calidad del dato.

____________________________________________________________________________________________________

(3) El nombre de la rama se muestra a modo de ejemplo y podría ser cualquiera que se consensuara.

Acceso de las aplicaciones al OVD

Llegado a este punto dado que todos los accesos serán hacia OID, hay que diferenciar entre dos tipos de aplicaciones:

1. Aplicaciones que consumirán sintaxis OID. Estas aplicaciones podrán explotar toda la información contenida en el OID, ya sea de identidades u organizativa. Por lo que el punto de acceso al OVD sería dc=juntadeandalucia,dc=es.
2. Aplicaciones que consumirán sintaxis OpenLDAP. Estas aplicaciones únicamente podrán explotar la información de identidades de la rama virtual, ya que sólo obtendrán en formato OpenLDAP, la referente a esta rama. El punto de acceso al directorio, sería entonces, o=personasOLD, o=identidades,o=comun,dc=juntadeandalucia,dc=es. Estas aplicaciones dejarán de poder acceder de forma anónima.

Por ejemplo, para el organismo CICE se traduciría en:

Donde las ramas principales serían:

• o=cice, sería la rama donde colgaría información corporativa del organismo.
• o=personas,sería la rama donde se encontrarían cada una de las identidades del organismo.
• o=personasOLD,sería la rama donde se encontraría cada una de las identidades del organismo pero con los atributos en formato OpenLDAP.

Resumen

Tal y como se ha ido argumentando la fase de transición de define a nivel de aplicación, por lo que en un mismo organismo se pueden encontrar aplicaciones de distinto tipo:

• Aplicaciones existentes en transición
• Aplicaciones existentes en fase final
• Aplicaciones nuevas en transición
• Aplicaciones nuevas en fase final

Por lo tanto el OVD del nodo local de cada organismos ofrecerá las siguientes entradas:

• dc=juntadeandalucia,dc=es: definida para la fase final de las aplicaciones.
  • o=personas,o=identidades,o=comun,dc=juntadeandalucia,dc=es. Muestra la estructura de directorio de OID con sintaxis de atributos de OID. De aquí consumirán información aquellas aplicaciones nuevas que están en fase final de integración.
  • o=pesonasOLD,o=identidades,o=comun,dc=juntadeandalucia,dc=es. Muestra la estructura de directorio de OID con sintaxis de atributos OpenLDAP. Para aplicaciones existentes que en fase final van a consumir información desde el directorio de GUIA, pero en formato OpenLdap. Este comportamiento, debe ser un comportamiento a extinguir.
• o=juntadeandalucia,c=es: definida para la fase en transición de las aplicaciones. Muestra la estructura de directorio de OpenLDAP con un merge de los atributos de OpenLDAP y los atributos de OID, estos últimos renombrados añadiéndole el prefijo GUIA_. De esta rama consumirán información tanto las aplicaciones existentes como las nuevas en transición.

Convivencia durante el periodo de transición con los controles definidos para OID a través de OVD.

• Control de anónimos. Este control se basa en la necesidad de evitar por temas de seguridad los accesos a OID no autenticados. Se aplica únicamente a la fase final de la transición, ya que sólo puede ser utilizado para los accesos dirigidos hacia OID, ya que hacia OpenLDAP, se deben respetar, puesto que está permitido el acceso no autenticado.
• Control de identificador válido. Este control será aplicado durante toda la vida de la aplicación. Se llevará un control de los identificadores con los cuales realizar las peticiones al OVD, denegando cualquier petición que no se realice con uno de estos identificadores. Los identificadores válidos aún están por decidir.
• Autenticación con diferente identificador.
  • Fase de transición. Las aplicaciones podrán autenticar identidades utilizando atributos de OpenLDAP, por ejemplo, los atributos jaDNI o uid (sería válido cualquier atributo que garantice la unicidad).
  • Fase final. Las aplicaciones podrán autenticar identidades utilizando atributos de OID, por ejemplo, los atributos numdoc o uid (sería válido cualquier atributo indexado que garantice la unicidad).