Captura en designer con la declaración de la variable y el objecto query
Ahora nos quedará por definir las propiedades de búsqueda como se puede ver en la siguiente captura , en este ejemplo buscamos en origen ( metadirecotry ) un objeto usuario de nombre alfredo ( cn = alfredo ) y queremos obtener su apellido y su dirección de email

Es importante definir el tipo de objeto de la variable a node-set , si no queremos tener problemas para recorrer el resultado. Una vez definido como node-set podremos usar expresiones xpath para consultar los resultados.

La ejecución de la función nos devolverá un documento XML del siguiente estilo

<nds dtdversion="3.5" ndsversion="8.x"> <source> <product version="3.6.10.4747">DirXML</product> <contact>Novell, Inc.</contact> </source> <output> <instance class-name="User" qualified-src-dn="O=Company\OU=Users\CN=alfredo" src-dn="\ARBRE\Company\Users\Alfredo" src-entry-id="33136"> <attr attr-name="CN"> <value naming="true" timestamp="1264497510#16" type="string">alfredo</value> </attr> <attr attr-name="sn"> <value naming="true" timestamp="1264497510#16" type="string">Garcia</value> </attr> <attr attr-name="Internet Email Address"> <value naming="true" timestamp="1264497510#16" type="string">agarcia@company.es</value> </attr> </instance> <status level="success"></status> </output></nds>

Este es el contenido de la variable $user ahora , mediante xpath podemos obtener los valores que deseamos.

$user/cn Para obtener el cn$user/sn Para obtener el surname

Eso es todo! para mas información sobre consultas xpath consultar la guia de la w3c

i=0
while read line
   do i=$(($i+1));
   echo $i $line
done < "/etc/passwd"
echo "Final line count is: $i";

El ejemplo lee el fichero /etc/passwd y muestra el número de línea ( variable $i ) y el contenido de la línea ( variable $line )

Espero que os sea igual de útil que me ha sido a mi para muchas cosas

Aún que este artículo se basa en la configuración para eDirectory , al ser LDAP un estándar de acceso a directorios es extrapolable a otros directorios como openLDAP ,Microsoft Active Directory, Sun iPlanet etc.., en este artículo sin embargo nos centraremos en Novell eDirectory.

La autentificación LDAP nativa es una de las nuevas características que nos trae la versión 1.5 de Joomla, para versiones anteriores existe un paquete llamado JAuth que nos permite hacer lo mismo, pero que en este artículo no vamos a tratar.

Para la configuración de la autentificación LDAP, deberemos conocer cómo funciona un directorio LDAP y como está estructurado nuestro directorio, si no es así deberíamos mirar la estructura de nuestro directorio mediante un cliente LDAP, y leer un poco de documentación sobre directorios LDAP.

Para configurar la autentificación en Joomla, primero de todo tendremos que activar el plugin de autentificación, para ello entramos como administradores en Joomla y nos situaremos en el menú Extensiones y seleccionamos Gestión de plugins.

Allí aparece una lista de todos los plugins disponibles, buscaremos y pincharemos en Authentication – LDAP, una vez allí aparecerá las opciones de configuración, primero de todo cambiaremos el Publicado a Sí.

A la izquierda hay una sección titulada “Parámetros del plugin”, allí nos pedirá algunos datos.

Servidor: Ponemos la dirección de nuestro servidor ip o nombre DNS

Puerto: Normalmente LDAP escucha por el puerto 389 pero esto es configurable en eDirectory por lo que tendremos que asegurarnos a través de que puerto escucha nuestro servidor LDAP.

Ldap V3: En mi caso Sí que queremos usar la versión 3 del protocolo LDAP

Negociar TLS: En entornos de desarrollo se puede dejar en deshabilitado, en entornos productivos debería esta en habilitado. Cuidado que eDirectory por defecto exige que todas las operaciones se hagan mediante TLS, para deshabilitarlo hay que modificar en nuestro eDirectory el objeto LDAP Server y LDAP Group y quitar el check “Exigir TLS para todas las operaciones”

Seguir referencias: No

Método de autorización: “Asegurar y buscar” o “Se asegura directamente como usuario”, la primera busca el usuario en cualquier rama del directorio, el segundo especifica donde hay que buscar el usuario, en mi caso lo tengo con Asegurar y Buscar.

Base DN: Distinguished name del objeto Base, O sea que objeto de nuestra estructura será la raíz de donde cuelgan el resto de objetos. Aquí podemos poner un objecto Organization si queremos buscar en toda la organización o una OrganizationalUnit si queremos buscar sólo en una OU, el valor de este parámetro dependerá de como hayamos estructurado nuestro directorio. Es importante que el usuario con el que nos queramos autentificar este siempre por debajo de este objeto, a uno o varios niveles si no, no seremos capaces de encontrarlo y la autentificación fallara.

Cadena a Buscar: Cómo buscaremos al usuario (porque atributo), en este caso lo buscaremos por el atributo cn con cn=[search] , aun que podríamos buscarlo por cualquier otro atributo con nombre_attr=[searc], si usamos “Se asegura directamente como usuario” tendremos que poner cn=[login]

Nombre de usuario para la conexión: Con que usuario nos conectaremos al directorio para poder buscar a los usuarios, hay que poner el usuario administrador o un usuario con permisos, por ejemplo cn=admin,o=directory.

Contraseña de conexión: Clave de este usuario

Mapear: Nombre Completo: Como se llama el atributo Nombre Completo en nuestro LDAP, en nuestro caso fullName

Mapear: E-mail: mail

Mapear: ID del usuario: cn

Joomla soporta varios métodos de autentificación simultáneamente, probando primero el primer plugin, luego el segundo etc. Con el parámetro “Ordenar” definiremos el orden del plugin en este caso como la autentificación primaria será el directorio LDAP le pondremos el valor 1.

Ahora ya podemos probar de autentificarnos con un usuario del directorio dentro de Joomla y en un principio tendría que funcionar.

Si la autentificación no funciona.
Es probable que hayamos cometido algún error en la configuración y que no nos funcione, Si no funciona debemos revisar la estructura de nuestro directorio con un visor LDAP ( por ejemplo Softerra LDAP browser ) , si está correctamente podemos usar el complemento de Joomla JDiagnostic el cual nos permite probar entre otras cosas los parámetros LDAP y la autentificación.

Un ejemplo seria poder sincronizar cuentas entre Microsoft Active Directory y una base de datos Oracle, logrando que cuando se diera de alta un usuario en Active Directory este mismo se replicara en la base de datos permitiéndose el acceso a ambos sistemas con la misma cuenta, obviamente no queda limitado a la conexión de dos sistemas si no que se puede conectar tantos sistemas como se requiera.

Esta funcionalidad se puede lograr mediante programas a medida o mediante soluciones de gestión de identidades, en el mercado hay varios fabricantes que han lanzado diferentes soluciones, algunas de estas son :

• Oracle Identity Management
• Sun Identity Manager
• Microsoft Identity Lifecycle Management
• Novell Identity Manager

Aún que cada una de estas soluciones tiene sus particularidades, el funcionamiento básico de estas soluciones esta compuesta por un repositorio central en el que se crean y mantienen los objectos y un motor que escucha cualquier cambio que se realice en el , altas , bajas, modificaciones etc… cuando se genera un evento en este repositorio central este es replicado a los sistemas conectados mediante el envío de documentos XML ,  así como a la inversa , cuando se produce un evento en uno de los sistemas conectados este es replicado hacia el repositorio central y, desde este, hacia todos los sistemas conectados.

Como resulta evidente nos puede interesar que no todos los sistemas se repliquen entre si , por ejemplo que sólo los objetos usuario se repliquen o que sólo se repliquen en uno de los sentidos, esto se configura mediante filtros, los filtros definen que objetos y que atributos de estos serán escuchados y en que sentido.

También hay que tener en cuenta que cada sistema conectado tiene sus particularidades , un ejemplo serían los atributos que , aun que almacenen el mismo tipo de datos no tienen por que llamarse igual , en un sistema el atributo que guarda el número de teléfono de un usuario puede llamarse “telephone number” y en otro “telephone”, o nos puede interesar que el valor de un atributo en destino sea la concatenación de dos atributos de origen, por ejemplo, en destino tenemos un atributo que se llama “nombre completo” pero en origen no lo tenemos y queremos rellenar este atributo con el nombre concatenado con el apellido.
Como tenemos estas particularidades, cada conexión entre el repositorio central y el sistema conectado tiene una serie de particularidades ,  por lo que se escriben unas reglas y políticas que modifican el documento XML que ha salido del sistema que ha generado el evento para adaptarlo a la arquitectura del sistema conectado. Al conjunto de reglas y políticas,  que modifican el documento XML con la descripción del evento le llamamos conector, normalmente los conectores viene configurados por defecto para que funcionen , pero casi siempre nos va a interesar modificarlos para adaptarlos a nuestras necesidades.

La replicación de cuentas , aún que es una de las partes mas importantes de estas soluciones sólo forma una mínima parte de lo que engloban estas soluciones, entre otras cosas permiten tener interfaces web para que los propios usuarios puedan mantener sus cuentas, requerir la aprobación de uno o varios usuarios para que un objeto de replique ( workflows ), tener roles etc..

“Duplicate engine id detected. This engine may not have been shutdown cleanly or another engine is running with engine-id: ENGINE01 . Waiting 60,000 ms for heartbeat to timeout.”

Esto es debido a que uno de los nodos del cluster no se ha cerrado bien y se queda a la espera , en principio esperando un tiempo prudencial tendría que arrancar , pero no siempre es así. Para forzar a arrancar el nodo tenemos que cambiar en la tabla de estado de los nodos el estado de dicho, eso se hace accediendo a la base de datos , en mi caso la por defecto , MySQL y consultando la tabla AFENGINESTATE.

En esta tabla podemos ver los dos nodos del cluster , llamados Engine01 y Engine02 , en este caso el Engine02 aparece arrancado cuando en verdad no lo esta, borramos el registro y volvemos a arrancar el nodo y veremos como ya no aparece y el nodo arranca correctamente.

El comando para borrar el registro podria ser por ejemplo este :

Ahora al volver a arrancar el servicio podremos ver como jboss y User Application vuelven a arrancar.

Existen dos tipos de sentencias SQL; Sentencias de ejecución, de las que sólo nos tenemos que preocupar de ejecutar,como es el caso de un update.O las sentencias de consulta, que nos devuelven un resultado, en este caso deberemos capturar el resultado y recorrer los valores segun nos convenga, como seria el caso de una sentencia select.

Sentencias de ejecución

Empecemos pues por el primer caso,por seguir un ejemplo,imagina que deseamos hacer una regla dentro de nuestro conector,que refleje en una tabla de eventos de la base de datos, cada modificación de un campo en Meta.

Con el fin de mantener este histórico, insertaremos un registro con el valor antiguo , el nuevo y el identificador de usuario cada vez que se propague un cambio de atributo desde el metadirectorio.

El codigo XML que necesitamos generar para ejecutar la sentencia es el siguiente :

<jdbc:statement event-id=”1″ jdbc:type=”insert” xmlns:jdbc=”urn:dirxml:jdbc”>

<jdbc:sql>insert into eventlog(newvalue,oldvalue,id) values(‘Jose’,'Manuel’,4)</jdbc:sql>

</jdbc:statement>

Encontramos un nodo jdbc:statement con el atributo event-id, que nos servirá como identificador de la sentencia ,el atributo jdbc:type con el tipo de sentencia que ejecutamos y el atributo xmlns:jdbc. Luego y como hijo del nodo jdbc:statement encontramos un nodo jdbc:sql con el codigo SQL de la sentencia que queremos ejecutar.

Para ello , dentro de nuestra regla DirXML construiremos el codigo anterior, usando la función append XML element() para añadir los nodos, luego a cada uno de los nodos le añadiremos los atributos usando la función set XML attribute() y finalmente le añadimos valor usando la función append xml text()

Observemos la siguiente regla, esta regla añade el código anterior en el documento XML que capturara el evento.

<rule>

<description>Reflejar cambio en tabla de eventos</description>

<comment xml:space=”preserve”>Inserta un registro en la tabla de eventos de la base de datos.</comment>

<conditions>

<and>

<if-class-name mode=”nocase” op=”equal”>User</if-class-name>

<if-association op=”associated”/>

<if-operation op=”equal”>modify</if-operation>

</and>

</conditions>

<action/>

<actions>

<!– Declaramos una variable con la sentencia SQL que queremos ejecutar –>

<do-set-local-variable name=”sql” scope=”policy”>

<arg-string>

<token-text xml:space=”preserve”>insert into eventlog(newvalue,oldvalue,id) values(‘,</token-text>

<token-op-attr name=”Given Name”/>

<token-text xml:space=”preserve”>’,'</token-text>

<token-attr name=”Given Name”/>

<token-text xml:space=”preserve”>’,'</token-text>

<token-association/>

<token-text xml:space=”preserve”>’)</token-text>

</arg-string>

</do-set-local-variable>

<!– Añadimos en nodo jdbc:statement –>

<do-append-xml-element expression=”/nds/input” name=”jdbc:statement”/>

<!– Añadimos atributo jdbc:type –>

<do-set-xml-attr expression=”/nds/input/jdbc:statement” name=”jdbc:type”>

<arg-string>

<token-text xml:space=”preserve”>update</token-text>

</arg-string>

</do-set-xml-attr>

<!– Añadimos atributo event-id –>

<do-set-xml-attr expression=”/nds/input/jdbc:statement[last()]” name=”event-id”>

<arg-string>

<token-text xml:space=”preserve”>0</token-text>

</arg-string>

</do-set-xml-attr>

<!– Añadimos dentro de jdbc:statement un nodo jdbc:sql –>

<do-append-xml-element expression=”/nds/input/jdbc:statement[last()]” name=”jdbc:sql”/>

<!– Le añadimos el contenido en este caso el de la variable sql definida arriba –>

<do-append-xml-text expression=”/nds/input/jdbc:statement[last()]/jdbc:sql[last()]“>

<arg-string>

<token-local-variable name=”sql”/>

</arg-string>

</do-append-xml-text>

</actions>

</rule>

La salida de dicha regla crea el texto resaltado en la traza.

<nds dtdversion=”3.5″ ndsversion=”8.x”>

<source>

<product version=”3.5.10.20070918 “>DirXML</product>

<contact>Novell, Inc.</contact>

</source>

<input>

<jdbc:statement event-id=“1″ jdbc:type=“insert” xmlns:jdbc=“urn:dirxml:jdbc”>

<jdbc:sql>insert into eventlog(newvalue,oldvalue,id) values(‘Jose’,'Manuel’,4)</jdbc:sql>

</jdbc:statement>

<modify class-name=”User” event-id=”idm-lab#20090309213232#1#1″ qualified-src-dn=”O=Organization\OU=Users\CN=User001″ src-dn=”\IDM-LAB\Organization\Users\User001″ src-entry-id=”45586″ timestamp=”1236634352#2″>

<association state=”associated”>ID_USUARIO=4,TABLE=usuarios</association>

<modify-attr attr-name=”Given Name”>

<remove-value>

<value timestamp=”1236634008#1″ type=”string”>Manuel</value>

</remove-value>

<add-value>

<value timestamp=”1236634352#2″ type=”string”>Jose</value>

</add-value>

</modify-attr>

</modify>

</input>

</nds>

Como podemos ver , la regla ha añadido el código XML con la sentencia SQL,  vamos a explicar las línea más relevantes del código :

<do-append-xml-element expression=”/nds/input” name=”jdbc:statement”/>

Añadimos debajo del nodo input que está debajo de nds un nuevo nodo llamado jdbc:statement ( Mirar el documento anterior )

<do-set-xml-attr expression=”/nds/input/jdbc:statement[last()]” name=”jdbc:type”>

<arg-string>

<token-text xml:space=”preserve”>update</token-text>

</arg-string>

</do-set-xml-attr>

A este nuevo nodo que hemos añadido ( /nds/input/jdbc:statement[last()] ) le añadimos un atributo nuevo llamado jdbc:type con el valor update. Notar que estamos usando XPath para seleccionar los nodos, en este caso el último nodo jdbc:statement debajo de /nds/input , ya que podrían haber varios nodos jdbc:statement y el que hemos añadido ahora sabemos que es el ultimo.

<do-set-xml-attr expression=”/nds/input/jdbc:statement[last()]” name=”event-id”>

<arg-string>

<token-text xml:space=”preserve”>0</token-text>

</arg-string>

</do-set-xml-attr>

Añadimos otro atributo al nodo ( /nds/input/jdbc:statement[last()] ) con nombre event-id y valor 0. Este atributo nos ayudara a identificar entre diferentes sentencias sql al usarlo como identificador de sentencia.

<do-append-xml-element expression=”/nds/input/jdbc:statement[last()]” name=”jdbc:sql”/>

Añadimos debajo el ultimo nodo jdbc:statement hijo de /nds/input un nuevo nodo llamado jdbc:sql

<do-append-xml-text expression=”/nds/input/jdbc:statement[last()]/jdbc:sql[last()]“>

<arg-string>

<token-local-variable name=”sql”/>

</arg-string>

</do-append-xml-text>

Ahora seleccionamos dicho nodo (el último nodo jdbc:sql del último nodo jdbc:statement ) y le añadimos contenido , en este caso el contenido de la variable sql definida anteriormente.

Sentencias de consulta

A la hora de lanzar sentencias SQL de tipo select, hay que tener en cuenta que hay que capturar el resultado de estas , el resultado vendrá por el canal publisher y lo podremos capturar en las reglas de input ,justo antes de las políticas de Schema Mapping.

Un ejemplo podría ser , lanzamos la siguiente consulta

<jdbc:statement event-id=”2″ jdbc:type=”insert” xmlns:jdbc=”urn:dirxml:jdbc”>

<jdbc:sql>select id_usuario as ‘Id Usuario’ from usuarios where ( nombre=’Miguel’ and apellido=’Gomez’ )</jdbc:sql>

</jdbc:statement>

Esta sentencia nos devolverá ( en las reglas de Input del canal Publisher ) el siguiente documento XML.

<nds dtdversion=”2.0″ ndsversion=”8.x” xmlns:jdbc=”urn:dirxml:jdbc”>

<source>

<product build=”20070918_0743″ instance=”Oracle-test” version=”3.5.2″>DirXML Driver for JDBC</product>

<contact>Novell, Inc.</contact>

</source>

<output>

<jdbc:result-set event-id=”2″ jdbc:number-of-rows=”1″>

<jdbc:row jdbc:number=”1″>

<jdbc:column jdbc:name=”Id Usuario” jdbc:position=”1″ jdbc:type=”java.sql.Types.NUMERIC”>

<jdbc:value>16254</jdbc:value>

</jdbc:column>

</jdbc:row>

</jdbc:result-set>

<status event-id=”0″ level=”success”/>

</output>

</nds>

Para poderlo capturar necesitaremos una regla para capturar el valor.

<rule>

<description>Capturar identificador de usuario</description>

<comment xml:space=”preserve”>Lee de la query anterior el valor para el identificador de usuario</comment>

<conditions>

<and>

<if-xpath op=”true”>/nds/output/jdbc:result-set[@event-id=2]</if-xpath>

</and>

</conditions>

<actions>

<do-set-local-variable name=”id_usuario” scope=”driver”>

<arg-string>

<token-xpath expression=”//jdbc:value”/>

</arg-string>

</do-set-local-variable>

<do-trace-message>

<arg-string>

<token-text xml:space=”preserve”>Proximo Valor </token-text>

<token-local-variable name=”id_usuario”/>

</arg-string>

</do-trace-message>

</actions>

</rule>

Vamos a comentar un poco las líneas de esta regla.

<if-xpath op=”true”>/nds/output/jdbc:result-set[@event-id=2]</if-xpath>

Entra en la regla si encuentra un atributo event-id con valor dos dentro de un nodo jdbc:result-set. Como habíamos comentado anteriormente el atributo jdbc:result-set nos sirve para identificar las sentencias sql.

<do-set-local-variable name=”id_usuario” scope=”driver”>

<arg-string>

<token-xpath expression=”//jdbc:value”/>

</arg-string>

</do-set-local-variable>

Cogemos el valor de todos los  nodos jdbc:value ( sólo tenemos uno ) y lo guardamos en la variable id_usuario.

En nodos jdbc:result-set con más de un valor y atributo la cosa se vuelve mas divertida, es cuestión de ir seleccionando los nodos que queremos mediante el uso de expresiones XPath.

Aquí un ejemplo de cómo podríamos recorrer todos los atributos Identificador

<do-for-each>

<arg-node-set>

<token-xpath expression=’/nds/output/jdbc:result-set/jdbc:row/jdbc:column[@jdbc:name="Identificador"]‘/>

</arg-node-set>

<arg-actions>

<do-set-local-variable name=”lista” scope=”policy”>

<arg-string>

<token-local-variable name=”lista”/>

<token-xpath expression=”$current-node/jdbc:value”/>

</arg-string>

</do-set-local-variable>

</arg-actions>

</do-for-each>

Tenemos un bucle for each donde vamos recorriendo todos los valores que nos devuelve la expresión XPath y concatenarlos en una variable llamada lista

Para finalizar el post , recomendaria leer la documentación de XPath de la W3C donde explica las funciones disponibles así como las formas de seleccioanar nodos.