Proyecto Fin de Carrera

1. ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA INFORMÁTICA
INGENIERÍA TÉCNICA DE INFORMÁTICA DE GESTIÓN
GESTIÓN INTEGRAL DE USUARIOS EN DRUPAL
Realizado por
ERNESTO ALGAR VALERO
52696992J
Dirigido por
ANTONIO RUIZ CORTÉS
Departamento
LENGUAJE Y SISTEMAS INFORMÁTICOS
Sevilla, Agosto de 2013

2. Índice de contenidos
1.Introducción......................................................................................7
1.1.Contexto del proyecto.................................................................7
1.2.Objetivos.....................................................................................9
1.3.Justificación..............................................................................10
1.4.Propuesta detallada..................................................................10
1.4.1.Introducción.....................................................................10
1.4.2.Participantes en el Proyecto............................................10
2.Metodologías de Desarrollo............................................................11
2.1.Scrum........................................................................................11
3.Planificación temporal y evaluación de costes...............................13
3.1.Planificación temporal..............................................................13
3.2.Evaluación de Costes................................................................16
4.Elicitación de requisitos.................................................................18
4.1.Introducción..............................................................................18
4.2.Participantes del proyecto........................................................18
4.3.Descripción del sistema actual.................................................20
4.3.1.OpenLDAP.......................................................................20
4.3.2.“Single Sign On”: CAS.....................................................27
4.4.Objetivos del sistema................................................................28
4.4.1.Gestión de Usuarios.........................................................30
4.4.2.Gestión de Roles..............................................................39
4.4.3.Consideraciones adicionales............................................42
5.Diseño del Sistema.........................................................................44
5.1.Introducción..............................................................................44
5.2.Arquitectura de Drupal.............................................................44
5.2.1.Módulos...........................................................................45
5.2.2.Drupal y MVC..................................................................46
6.Diseño de datos...............................................................................48
6.1.Diagrama Entidad - Relación del Sistema................................48
6.2.Entidades del Modelo de Datos................................................50
6.3.Relaciones del Modelo de Datos...............................................52
2

3. 7.Codificación....................................................................................53
7.1.Entorno de programación y Herramientas...............................53
7.2.Lenguajes de programación.....................................................54
7.3.Otros aspectos relevantes de la implementación.....................57
8.Conclusiones...................................................................................63
9.Glosario de términos.......................................................................65
10.Referencias...................................................................................66
11.Bibliografía...................................................................................68
3

4. Índice de Tablas
Planificación_del_proyecto......................................................................................15
Costes_de_software................................................................................................. 17
Presupuesto_del_proyecto.......................................................................................17
Participante_del_proyecto:Ernesto_Algar_Valero...................................................18
Participante_del_proyecto:Antonio_Ruíz_Cortes.....................................................19
Organización_LSI.................................................................................................... 19
Objetivos_del_sistema.............................................................................................29
Gestión_de_Usuarios:Atributos...............................................................................30
Gestión_de_Usuarios:Campos.................................................................................31
Gestión_de_Usuarios:Aplicaciones..........................................................................31
CRUD_de_Usuarios:Nuevo_Usuario........................................................................33
Modelo_de_Datos:GIU_USERS................................................................................50
Modelo_de_Datos:GIU_PROFILES..........................................................................50
Modelo_de_Datos:GIU_USERS_PROFILES.............................................................50
Modelo_de_Datos:GIU_ENVIRONMENT_PROFILES..............................................51
Relaciones_del_modelo_de_datos_1........................................................................52
Relaciones_del_modelo_de_datos_2........................................................................52
Relaciones_del_modelo_de_datos_3........................................................................52
Herramientas_usadas.............................................................................................. 54
4

5. Índice de Figuras
Figura
Figura
Figura
Figura
Figura
Figura
Figura
Figura
Figura
Figura
Figura
Figura
Figura
Figura
Figura
Figura
Figura
Figura
Figura
1.1 – Activación del módulo.........................................................................10
4.1 – Estructura de OpenLDAP....................................................................23
4.2 – configuración OpenLDAP en Drupal (Server settings)........................24
4.3 – configuración OpenLDAP en Drupal (Login procedure).....................25
4.4 – configuración OpenLDAP en Drupal (Advanced configuration)..........26
4.5 – Esquema de autenticación con SSO-CAS............................................27
4.6 – Listado de usuarios.............................................................................32
4.7 – Ficha de alta de un nuevo usuario......................................................35
4.8 – Detalle de usuario...............................................................................37
4.9 – Borrado de usuarios............................................................................38
4.10 – Detalle de perfil................................................................................40
5.1 - Esquema de la arquitectura de Drupal...............................................44
5.2 - Inversion of Control............................................................................45
5.3 – Estructura de módulos........................................................................46
5.4 - MVC..................................................................................................... 47
5.5 - Patrón arquitectónico MVC................................................................47
6.1 - Diagrama entidad-relación..................................................................49
7.1 - Entornos.............................................................................................. 53
6.2 – database.config.php............................................................................57
5

6. 6

7. 1. Introducción
1.1.
Contexto del proyecto
Drupal es un sistema de administración de contenidos Web
especialmente versátil. En sus orígenes el sistema estaba dirigido a dar
soporte a una comunidad de Weblog. Su desarrollo fue iniciado en
2009 por Dries Buytaert en 1999 y no fue hasta 2001 cuando se
publico la primera versión del CMS. Hasta el lanzamiento de la versión
4.0.0,
Drupal
publicaba
una
versión
anualmente,
tras
ésta, el
lanzamiento de cada nueva versión base, se ha ralentizado a una cada
2 o 3 años, publicando entre 10 y 20 versiones menores sobre cada una
de las versiones base. Actualmente Drupal se encuentra en la versión
7.23.
Drupal no está dirigido a un tipo de escenarios específico. El
límite de este CMS lo impone el desarrollador; al igual que ocurre con
muchos otros CMS, es necesario disponer de un buen conocimiento y
experiencia en dicha solución para sacarle el máximo partido.
Son muchas las características que sitúan a Drupal entre los
CMS más destacados del mercado:
 Dispone de un entorno de personalización robusto, tanto el
contenido como la presentación pueden ser tratados de forma
individual de acuerdo a unas preferencias definidas por el
usuario. La gestión de contenido se realiza como objetos
independientes, de forma que puede realizarse un tratamiento
individualizado de la información, facilitando su inclusión en
cualquier página o permitiendo comentarios específicos sobre
cada uno de ellos.
7

8.  Los mecanismos de actualización de contenidos son realmente
sencillos, permite editar la mayor parte de los contenidos tanto
desde el frontend como desde el backend.
 Ofrece
la
posibilidad
de
gestionar
las
taxonomías
y
la
estructuración de contenidos de forma personalizable, algo
indispensable para sitios de complejidad media-alta.
 Desde el punto de vista de la seguridad, la gestión de permisos
destacaba por encima de cualquier otra característica; ofrece un
sistema muy avanzado y completamente personalizable a nivel de
rol y páginas.
 El rendimiento y la escalabilidad son otras de sus señas de
identidad: sistema de cache avanzado, replicación de base de
datos, balanceo de cargo, mecanismos de control de congestión
configurable para habilitar o deshabilitar módulos, etc.
 La comunidad de desarrolladores es otro de los puntos fuertes de
Drupal, ofreciendo un desarrollo dinámico y un soporte amplio
basado en foros Web.
 Dispone
de
agrupadas
cientos
según
Administración,
de
extensiones,
funcionalidad
Controlo
de
en
Acceso,
estás
se
encuentran
distintas
categorías:
Eventos,
Comercio,
Comunidad, Contenidos, Gestión de usuarios, Búsquedas, etc.
Con respecto a las características más técnicas, cabe mencionar
que Drupal se encuentra liberado bajo licencia GPL y utiliza PHP como
lenguaje de programación, MySQL como motor de base de datos,
aunque también puede funcionar con PostgreSQL o SQLite, y Apache o
Microsoft IIS como servidor Web.
Con Drupal es posible desarrollar cualquier tipo de portal o
aplicación web. Además de las funcionalidades básicas que vienen
8

9. integradas en el software, es posible añadir nuevas funcionalidades a
través de módulos.
Los módulos son aplicaciones adicionales desarrolladas por
miembros de la Comunidad de Drupal, que se distribuyen libremente
bajo la misma licencia GPL. Cualquier persona puede crear un nuevo
módulo o modificar uno existente.
1.2.
Objetivos
Nos encontramos con un conjunto de aplicaciones, que a la hora
de registrarse en cada una de estas, se tienen que hacer de forma
independiente, esto es, que se tiene que dar de alta a un mismo
usuario en todas las aplicaciones de forma individual.
El objetivo de este proyecto es presentar al administrador que
gestiona todas las aplicaciones, un sistema de gestión de usuarios
centralizado, donde pueda gestionar toda la logística de los permisos y
roles de las diferentes aplicaciones.
La idea es que con el alta de un usuario, este pueda acceder a
todas las aplicaciones con ese mismo usuario, sin tener que darse de
alta en todas, o lo que es lo mismo, realizar un “Single Sign On” para
acceder a cada una de la aplicaciones que integremos.
Para llevar a cabo esta tarea se va a desarrollar un módulo en
Drupal,
donde se va
a implementar toda
la
funcionalidad de
integración.
Figura 1.1 – Activación del módulo
9

10. 1.3.
Justificación
La tarea de desarrollar este módulo en Drupal parte de la idea
de poder facilitar el trabajo al encargado de administrar el conjunto
de las aplicaciones.
Con esta herramienta se pretende que no se tenga que dar de
alta a un usuario en todas las aplicaciones de forma individual, sino
que cuando se realice en registro de un usuario, se pueda dar de alta
en todas.
1.4.
Propuesta detallada
GESTIÓN INTEGRAL DE USUARIOS EN DRUPAL
1.4.1.
Introducción
El proyecto a realizar consiste en desarrollar un módulo que se
integre en el CMS Drupal y que permita tener una zona de
administración de usuarios única donde se integren las demás
aplicaciones que dependen de él.
1.4.2.
Participantes en el Proyecto
Los participantes en este proyecto fin de carrera son:
Ernesto Algar Valero alumno de Ingeniería Técnico de
Informática de Gestión por la Escuela Técnica Superior de Ingeniería
Informática de la Universidad de Sevilla, el cual realizará el
desarrollo completo del módulo.
Antonio Ruíz Cortes profesor titular del Departamento de
Lenguajes y Sistemas Informáticos por la Universidad de Sevilla,
encargado de la supervisión y control de desarrollo completo del
sistema.
10

11. 2.Metodologías de Desarrollo
Las Metodologías de Desarrollo de Software surgen ante la
necesidad
de
utilizar
una
serie
de
procedimientos,
técnicas,
herramientas y soporte documental a la hora de desarrollar un
producto software.
Dichas metodologías pretenden guiar a los desarrolladores al
crear un nuevo software, pero los requisitos de un software a otro
son tan variados y cambiantes, que ha dado lugar a que exista una
gran variedad de metodologías para la creación del software. Se
podrían clasificar en dos grandes grupos:
• Las metodologías orientadas al control de los procesos,
estableciendo rigurosamente las actividades a desarrollar,
herramientas a utilizar y notaciones que se usarán. Estas
metodologías son llamadas Metodologías Pesadas.
• Las metodologías orientadas a la interactuacción con el
cliente y el desarrollo incremental del software, mostrando
versiones parcialmente funcionales del software al cliente
en intervalos cortos de tiempo, para que pueda evaluar y
sugerir cambios en el producto según se va desarrollando.
Estas son llamadas Metodologías ligeras/ágiles.
2.1.
Scrum
La metodología ágil surge en entornos donde las definiciones
de productos o servicios cambian con relativa facilidad y la
obsolescencia de las tecnologías utilizadas es relativamente rápida.
Esto da lugar a que decisiones tomadas durante la planificación
inicial de un proyecto sean interesantes modificarlas con la menor
trascendencia posible en el proyecto.
11

12. Scrum
es
un
marco
de
referencia
para
generar
una
metodología ágil. Es un marco que surgió de la experiencia y se
mantiene activo y evolucionando. El principal objetivo de Scrum es
llevar los proyectos a su realización final cuando están envueltos en
entornos
cambiantes,
como
es
el
mundo
del
software
y
especialmente el entorno web. A diferencia de la metodología ágil,
Scrum concretiza los pasos a seguir para alcanzar los objetivos
propuestos.
La metodología de Scrum se sustenta sobre 3 principios:
transparencia, inspección y adaptación. Los tres principios de esta
metodología tienen la misma importancia.
Transparencia hace referencia a que todos los agentes
implicados deben estar al corriente de los cambios, contratiempos o
impedimentos que surjan.
La inspección quedará cubierta por medio de las reuniones y
trabajos en equipo que plantea la metodología, para detectar las
desviaciones con la mayor brevedad posible.
Adaptación es uno de los principios básicos de la metodología
ágil y uno de los objetivos por los que se aplica Scrum. Consiste en
introducir los cambios que puedan surgir con la menor implicación a
los objetivos del proyecto [1-6].
Como se ha llevado a cabo en el proyecto
Para el desarrollo de este proyecto se detectó que se
necesitaba una metodología ágil que permitiera introducir cambios
en el proyecto. Esto era debido a que las especificaciones no eran
totalmente cerradas y en la medida que avanzara el proyecto podía
ser interesante priorizar tareas o incluso redefinirlas.
12

13. 3.Planificación temporal y evaluación de
costes
Para que un proyecto sea exitoso, es importante cumplir los plazos
acordados con antelación y no sobrepasar los costes estimados. Para
ello una buena planificación temporal y de costes es de suma
importancia.
3.1.
Planificación temporal
Es una actividad que el gestor realiza distribuyendo el esfuerzo
estimado a lo largo de la duración prevista del proyecto, asignando
el esfuerzo a las tareas específicas de la ingeniería del software.
Debemos tener en cuenta varios aspectos fundamentales:
 Personal integrante del proyecto, es importante conocer las
cualidades y conocimientos de los participantes para delegar
en ellos las tareas que más se adapten a cada persona.
 Producto, hay que tener claro el producto a desarrollar antes
de iniciar la planificación, determinar los objetivos, identificar
dificultades técnicas y de gestión, de lo contrario, no sabremos
estimar el tiempo de desarrollo.
 Proceso, una vez conocido el producto y sus dificultades, es
esencial
crear
un
diagrama
de
dependencias
entre
las
actividades y las tareas que componen cada una de ellas.
 Proyecto, no es menos importante identificar los factores de
riesgo, con el fin de poder dirigirlos y controlarlos.
Una vez explicados los puntos a tener en cuenta en la
planificación, procederemos a definir los tiempos estimados en cada
labor.
13

14. Por tanto, dividimos el ciclo de vida del proyecto en una serie
de tareas a las cuales se les asignará las dos estimaciones
siguientes:
Tiempo estimado empleadas en los inicios del desarrollo. Son
las menos exactas, pero se emplean como primera aproximación a la
viabilidad del proyecto.
Tiempo real expresan la duración y el esfuerzo real empleado,
cuyos valores se compararán para evaluar la exactitud de la
estimación, empleando el Error Relativo de la estimación, RE.
Considerando que el proyecto académico consta de 9 créditos
y cada cual son 30 horas lectivas por crédito, hacen un total de 270
horas. Por tanto, el reparto de tareas es:
14

15. Tarea
Tiempo estimado
Tiempo real
RE
Búsqueda documentación
8h
13h
38.5%
Introducción
15h
10h
-50%
Planificación temporal
2h
1h
-100%
Evaluación de costes
3h
2h
-50%
Elicitación de requisitos
18h
28h
35.7%
Análisis del sistema
18h
33h
45.4%
Diseño del sistema
20h
25h
20%
Codificación
171h
231h
26%
Pruebas
8h
8h
0%
Manual de Usuario
7h
9h
22.2%
TOTAL
270h
360h
25%
Tabla 3.1 - Planificación del proyecto
La desviación viene provocada por el número de aplicaciones
que se quieren controlar desde la gestión de usuarios, se tienen que
crear las clases especificas para poder realizar la integración con el
módulo a crear y que no haya conflictos entre ellas.
15

16. 3.2.
Evaluación de Costes
Para la evaluación de costes, tendremos en cuenta los
diferentes puntos a valorar:
 Coste
de
personal,
corresponderá
al
total
de
horas
empleadas por los distintos integrantes del proyecto.
 Coste social, es el gasto asociado a la Seguridad Social a
cargo de la empresa. Este gasto tiene un porcentaje que oscila
entre el 31% al 35% del salario bruto anual.
 Coste de hardware, contemplará el precio del equipo usado
durante la realización de la aplicación.
 Coste
de
software,
valor
del
conjunto
de
programas
necesarios.
Coste de personal, teniendo en cuenta que el salario anual de
un técnico medio no doctorado es 15.640,30 €, y que al año se
trabajan una media de 50 semanas con 5 días laborables y 8 horas
cada jornada, obtenemos que el precio/ hora es 7,82 €.
Con este valor, y dado que el número de horas a dedicar en
este proyecto académico es 270, llegamos a un total para este
apartado de 2.111,4 €.
Coste social, como vemos, si el trabajador tiene un salario
bruto de 2.111,4 €, la seguridad social que se tiene que pagar por
este trabajador oscila entre 654 € a 739 € todos los meses.
Coste hardware, aquí incluimos el precio de un ordenador
portátil. Dado que el precio del portátil es de 800€ con un coste de
amortización de 4años, y suponiendo una duración de proyecto de 4
meses, obtenemos un total de:
16

17. 800 x 4 / (4 x 12) = 55,67 €
Costes software, utilizaremos los siguientes programas:
Eclipse Helios
0,00 €
Microsoft Office
381,98 €
Apache incluido en XAMPP
0,00 €
MYSQL
0,00 €
Total
381,98 €
Tabla 3.2 - Costes de software
Al que aplicamos el mismo coste de amortización que para el
hardware obtenemos:
381,98 x 4 / (4 x 12) = 31,83 €
Presupuesto
Concepto
Precio
Personal
1.759,5 €.
Hardware
55,67 €
Software
31,83 €
Total
1847 €
Tabla 3.3 - Presupuesto del proyecto
17

18. 4.Elicitación de requisitos
4.1.
Introducción
En este apartado se ofrecerá una visión detallada del módulo
que se va a crear. Por ello primeramente describiremos la
plataforma en la actualidad. Luego los objetivos que queremos
conseguir, y seguidamente los requisitos del sistema, tanto de
información, como funcionales (casos de uso) como no funcionales.
Por último, presentaremos las matrices de rastreabilidad dividida en
subsistemas y presentaremos un glosario de términos.
4.2.
Participantes del proyecto
Participante
Ernesto Algar Valero
Organización
Freelance
Rol
Desarrollador
Es desarrollador
Sí
Es cliente
No
Es usuario
No
Comentarios
Autor del proyecto
Tabla 4.1 - Participante del proyecto: Ernesto Algar Valero
18

19. Participante
Antonio Ruíz Cortes
Organización
Freelance
Rol
Tutor
Es desarrollador
No
Es cliente
No
Es usuario
No
Comentarios
Tutor del proyecto
Tabla 4.2 - Participante del proyecto: Antonio Ruíz Cortes
Organización
Departamento de Lenguajes y Sistemas
Informáticos
Dirección
Av/Reina Mercedes s/n
CP: 41012 (Sevilla)
Teléfono
954555964
Fax
954557139
Comentarios
Departamento de Lenguajes y Sistemas Informáticos – L4
Correo: buzon@lsi.us.es
Web: www.lsi.us.es
Tabla 4.3 - Organización LSI (Departamento de Lenguajes y Sistemas
Informáticos)
19

20. 4.3.
Descripción del sistema actual
Actualmente la gestión de usuarios está diseñada por medio de
un directorio LDAP y un “Single Sign On".
Para ayudar en la tarea de la gestión de los usuarios y grupos
de ellos se define el uso de OpenLDAP como directorio en red. El uso
de esta herramienta no solo aporta una mayor flexibilidad en la
gestión de usuarios, sino también un sistema independiente y
estándar para compartirlos con otras aplicaciones y servicios.
OpenLdap es una implementación del servidor LDAP de código
abierto. Un servidor de LDAP ofrece un servicio de directorio en red.
Este tipo de servicio es de interés para usos como una guía de
contactos, guía telefónica, directorio de correo electrónico, servidor
de dns o autenticación de usuarios.
Finalmente, se añade un servicio de “Single Sign On” que
aporta valor añadido y comodidad de uso. Es altamente valorado por
los usuarios puesto que permite unificar la tarea de autenticación
para todos los servicios web sobre los que se tenga el control. De
esta forma, no es necesario introducir usuario y contraseña
constantemente.
4.3.1.
OpenLDAP
OpenLdap es una implementación del servidor LDAP de código
abierto. Un servidor de LDAP ofrece un servicio de directorio en red.
Este tipo de servicio es de interés para usos como una guía de
contactos, guía telefónica, directorio de correo electrónico, servidor
de dns o autenticación de usuarios.
Las características que destacan en un servidor LDAP son: la
alta velocidad en lectura de datos y la baja velocidad en escritura y
modificación. Estas características hacen que este tipo de servidor
20

21. sea interesante para almacenar información relativamente estática,
pero de muchas lecturas. El protocolo que utiliza el servidor LDAP
está orientado a trabajar en red y presenta características de
entorno distribuido, que facilita la replicación de la información a
múltiples servidores al mismo tiempo, es decir, que se pueden
actualizar los datos en diversos servidores LDAP al mismo tiempo.
LDAP se organiza por medio de una estructura jerárquica
orientada a representar y contener objetos y elementos. Este tipo de
organización representa de forma adecuada, un gran número de
relaciones existentes en la realidad. Esta organización acompañada
de los atributos multivalor que describen los objetos, dan unas
propiedades adecuadas a LDAP para describir relaciones reales.
Con la información expuesta, puede parecer que LDAP no es
más que una base de datos pero, su protocolo orientado a funciones
de directorio en red y su optimización para lectura unido a la
estructura jerárquica, hacen de este sistema, uno de los mas
instalados para la gestión de usuarios y agendas de contactos, a la
vez que, la convierte en poco eficiente para almacenar otros tipos de
datos. Esta estructura jerárquica aumenta notablemente los tiempos
de escritura pero, facilita la lectura. Por ese motivo, los datos que se
guardan en este tipo de servidor son información que se consulta un
gran número de veces pero, se escribe poco.
Otra virtud que presenta LDAP es que, para temáticas como la
gestión de usuarios, incorpora un mecanismo de autenticación para
el cliente que quiere acceder a la información contenida en el
servidor LDAP. De esta forma se limita el acceso a los datos que
contiene.
Un directorio LDAP se compone de un árbol ordenado de
entradas pudiendo representar algunas dependencias entre ellos a
nivel conceptual. Las entradas del árbol constan de un nombre que
21

22. los identifica de forma única y una serie de atributos. Los atributos
están formados por un nombre que ejerce de llave y uno o varios
valores para ese atributo. Los atributos que aplican a cada entrada
dependen del esquema que se aplique. Cada entrada del árbol queda
definida por un esquema que indica los atributos que esta entrada
debe o puede tener, según si son atributos obligatorios o opcionales.
Por último, se tiene que recordar que en los directorios LDAP la
posición de la entrada en el árbol, seguido del nombre de la entrada,
es el “Distinguished Name”, que se utiliza como identificador único
de la entrada y no pueden existir 2 iguales [13].
Herramienta para gestionar LDAP
En nuestro caso se ha probado JXplorer [14], que está
desarrollada en java y permite la conexión con LDAP indicándole el
puerto al que acceder.
•
Esquema OpenLDAP para Drupal
En este proyecto se ha desarrollado un esquema para
OpenLDAP basándonos en el uso de LDAP como directorio de
usuarios y principalmente en su conexión con Drupal.
Se ha trabajado primero con los conceptos que emplea Drupal
en la gestión de usuarios, para poder definir una buena estructura
en LDAP. Dentro del esquema de LDAP, se van a almacenar los
usuarios, para que desde Drupal se pueda gestionar con comodidad
la adhesión a otras aplicaciones de los usuarios.
El esquema empleado muestra la rama de los usuarios existes
en un listado. Los atributos que los definen vienen determinados por
los esquemas básicos “top, person, inetOrgPerson”.
22

23. Figura 4.1 – Estructura de OpenLDAP
•
La
Conexión OpenLDAP con Drupal
conexión
de
OpenLDAP
con
Drupal
se
realiza
completamente por medio de la interfaz gráfica de Drupal.
El administrador del portal debe ir a la zona de administración
y dentro de Configuración del sitio, seleccionar la modalidad LDAP.
Una vez dentro, se deben configurar los parámetros como
corresponda para el servidor LDAP que se va a utilizar, en este caso
OpenLDAP.
Se debe indicar la máquina y puerto de OpenLDAP, y entregar
un usuario con permisos suficientes para poder modificar la rama del
árbol donde se almacenan los usuarios de Drupal.
23

24. Figura 4.2 – configuración OpenLDAP en Drupal (Server settings)
24

25. Figura 4.3 – configuración OpenLDAP en Drupal (Login procedure)
25

26. Figura 4.4 – configuración OpenLDAP en Drupal (Advanced configuration)
Una vez realizado el proceso, ya se puede comprobar si ha
funcionado, intentando acceder con un usuario de OpenLDAP que no
exista en Drupal. Los usuarios de Drupal se iran exportando a
OpenLDAP en la medida que vayan accediendo al portal.
¿Quien autentica los usuarios?
En este escenario los usuarios siguen siendo autenticados y
gestionados por Drupal. La única diferencia de la del uso normal es
que Drupal no consulta sus bases de datos para determinar los
usuarios y su contraseña, sino que emplea OpenLDAP para este fin.
La ventaja que esto representa, es poder compartir los usuarios de
Drupal con otras aplicaciones.
26

27. 4.3.2.
“Single Sign On”: CAS
Un “Single Sign On” es un proceso de autenticación unificado,
que permite al usuario introducir una única vez el nombre de usuario
y contraseña para acceder a varias aplicaciones. El proceso de
“Single Sign On” autentifica una vez al usuario para esa sesión, y le
dará acceso a todas aquellas aplicaciones donde tenga permisos
para acceder, eliminando la tarea de introducir usuario y contraseña
cada vez que cambia de aplicación durante la misma sesión [7] [8].
La autenticación del “Single Sign On” para entornos web se
realiza por medio de tiquets, que son almacenados en el servidor
SSO y en una cookie en el navegador del cliente. Al acceder el
usuario a las aplicaciones, estas consultan con el servidor de SSO
para verificar que coincide el tiquet almacenado en el servidor SSO
con el proporcionado por el navegador en la cookie.
Figura 4.5 – Esquema de autenticación con SSO-CAS [8]
27

28. CAS
CAS (Central Authentication Service) es una aplicación java
desarrollada por la universidad de Yale que se compone de un
servidor de autenticación que implementa el SSO, y de un cliente de
autenticación, que actualmente tiene desarrollado conectores para
varios lenguajes de programación como son java, php, .NET y perl.
Por seguridad, el servidor CAS debe ser accedido por medio de
protocolo de capa segura SSL (https), que es el utilizado en entornos
web para enviar la información cifrada entre el navegador del cliente
y el servidor web.
4.4.
Objetivos del sistema
Se pretende con la solución propuesta por un lado:
 La
información
está
distribuida
en
cada
una
de
las
herramientas. No tener datos propios en la herramienta para
evitar problemas de sincronización de datos.
 Permitir la escalabilidad de la gestión de usuarios en la
aplicación, al añadir nuevas herramientas a la misma.
 Preservar la integridad de los datos de usuarios a lo largo de
toda la aplicación.
La idea es que la Gestión Integral de Usuarios, haga los
mantenimientos correspondientes en cada una de las herramientas
de forma lo más transparente posible al usuario.
La gestión de usuario parte de una información mínima, y
añade nuevos atributos en función de los que requiera cada nueva
herramienta. Cada nueva herramienta debe proporcionar el listado
de atributos que puede manejar y los que necesita para considerar
un nuevo usuario.
28

29. Esta información se carga al inicio de la aplicación de Gestión
de Usuarios. Se añaden nuevos atributos consultando a cada
herramienta.
La gestión de roles, se delega igualmente en cada herramienta,
de modo que cada una proporciona el formulario de roles y ámbitos
definidos en la misma, así como los que tiene un usuario asignados.
Si en una herramienta, no existe el concepto de ámbito, no se
mostrará nada como ámbito.
Si existen modificadores al ámbito (como la recursividad) lo
podrá gestionar adecuadamente el formulario de cada herramienta.
Si una herramienta no devuelve ningún rol, no se mostrará su
zona de asignación en el formulario (por ejemplo, para el caso del
LDAP).
Formulario de Edición de Usuario
Identificador
Atributo 1
Atributo 2
…
Botones de Guardar - Borrar
App1
App2
App3
Formulario de edición de Roles de App1
29

30. 4.4.1.
Gestión de Usuarios
Un usuario en la Gestión Centralizada de Usuarios constará de
un identificador único de usuario, que se identifica con el login de
usuario que devolverá CAS, y un listado de atributos.
 Identificador
 Atributos
Los atributos dependerán del número de aplicaciones que
queramos gestionar, de modo que para cada sistema existirán una
serie de atributos, cada uno de los cuales podrá ser obligatorio o no
y de un tipo determinado.
Los atributos tendrán una etiqueta con la que se identificarán,
y para cada aplicación puede tener diferentes nombres. De modo
que el atributo con etiqueta “correo electrónico”, tendrá su
representación en la aplicación GLPI en el campo email, y en la
aplicación Drupal en el campo email.
Para mostrar la información de un usuario, los atributos
tendrán además un atributo de peso que determinará el orden en
que se muestran los mismos.
Attributes
Descripción
label
Etiqueta que se mostrará en el formulario
de CRUD de Usuarios.
weight
Orden en que se mostrará el campo en el
formulario de CRUD de Usuarios
30

31. Fields
Descripción
app
Identificador de la aplicación a integrar
label
Campo de usuario al que se corresponde.
field_name
Nombre del campo en la aplicación
field_widht
Ancho del campo en la aplicación
mandatory
Obligatorio o no
El CRUD de usuarios tomará la información de la aplicación
predeterminada (de peso menor), y mostrará el resto de información
de las demás aplicaciones. No existe información de usuarios local al
módulo de Gestión de Usuarios, sino que se toma de las aplicaciones
integradas. La única información de la que dispone el módulo es de
la de configuración y acceso a las diferentes aplicaciones.
Applications
Descripción
app
Acrónimo de la aplicación
app_name
Nombre de la aplicación
app_desc
Descripción de la aplicación
weight
Prioridad de la aplicación
31

32. CRUD de Usuarios: Listado de Usuarios
El listado de usuarios toma la información de la lectura de
usuarios de la función ListUsers de la aplicación predeterminada.
Esta función devuelve un listado de identificador y atributos, que el
formulario de listado formateará para darle el estilo adecuado.
Cada entrada de usuario incluirá, para los usuarios con
privilegios para ello, una opción de acceso al formulario de edición
de ese usuario.
El formulario de listado de usuarios incluye, para los usuarios
con privilegios para ello, una opción de “nuevo usuario” que da
acceso al formulario de edición de usuario sin parámetro de usuario.
Figura 4.6 – Listado de usuarios
32

33. CRUD de Usuarios: Nuevo Usuario
El formulario de nuevo usuario, muestra una sección de
información con la información propia del usuario. Cada campo del
formulario se obtiene de recorrer los atributos en orden de menor a
mayor peso y montándolos dinámicamente con el ancho de campo
más restrictivo (el menor) de las aplicaciones a las que corresponda.
Por ejemplo:
Dos aplicaciones: LDAP (peso 1) y GLPI (peso 2).
Dos Atributos: Nombre (peso 1) y Correo Electrónico
(peso 2)
Campos:
app
label
field_name
field_width
mandatory
LDAP
Nombre
givenname
40
Y
GLPI
Nombre
firstname
60
N
GLPI
Correo
email
80
N
Electrónico
33

34. Mostraría un formulario con 3 entradas:
 Identificador. Siempre se mostrará en primera posición. En
edición siempre será de sólo lectura.
 Nombre: de ancho 40 (el más restrictivo) y además será
obligatorio.
 Correo electrónico: de ancho 60 (el más restrictivo) y además
será
opcional,
ya
que
ninguna
aplicación
lo
considera
obligatorio.
Una vez rellenos los campos obligatorios, y aceptada la
creación del usuario, se produce una validación de campos. Como
paso previo a guardar los datos se hará una llamada a todas las
funciones de getAttributeValidation de cada Label, que a su vez hará
una llamada a getFieldValidation de cada aplicación. Si alguna de
estas da errror de validación, se vuelve al formulario de edición de
usuario con un mensaje de advertencia destacado que corresponda
en cada caso al error de validación cometido.
Finalmente, la creación del usuario se realiza en cada
aplicación mediante la correspondiente llamada a la función
CreateUser con los atributos necesarios para cada una de ellas.
34

35. Figura 4.7 – Ficha de alta de un nuevo usuario
35

36. CRUD de Usuarios: Edición de Usuario
El formulario de edición de usuario, muestra una sección de
información con la propia del usuario, y otra con la de los roles por
cada aplicación (que se especifica más adelante).
El formulario se monta de forma dinámica tal y como se
describe en el anterior apartado, pero tomando los datos de cada
campo del formulario de la aplicación de mayor peso.
De modo que para el ejemplo anterior, en cada caso se
llamaría a la función getLabelValue para cada label, y en cada caso
se
haría
la
correspondiente
llamada
al
de
la
aplicación
correspondiente. getAttributeValue(“Nombre”) devolvería el valor de
getFieldValue(“LDAP”, “givenname”), al tener la aplicación APP más
peso que GLPI, y getAttributeValue(“Correo electrónico”) devolvería
el valor de getFieldValue(“GLPI”, “email”) al no tener ese campo la
aplicación LDAP.
A la hora de aprobar los cambios realizados en el formulario,
como paso previo a guardar los datos se hará una llamada a todas
las funciones de getAttributeValidation de cada Label, que a su vez
hará una llamada a getFieldValidation de cada aplicación. Si alguna
de estas da errror de validación, se vuelve al formulario de edición
de
usuario
con
un
mensaje
de
advertencia
destacado
que
corresponda en cada caso al error de validación cometido.
Una vez comprobadas todas las validaciones, se realizará la
actualización
de
cada
uno
setAttributeValue(attribute,value),
de
que
los
atributos,
hará
las
mediante
respectivas
setFieldValue(field,value) de cada una de las aplicaciones.
36

37. Figura 4.8 – Detalle de usuario
37

38. CRUD de Usuarios: Edición de Usuario (no existe)
Cuando se edita un usuario que no existe en una determinada
herramienta (se puede dar el caso por diversas situaciones), se debe
dar de alta el nuevo usuario en la herramienta de forma automática.
Si para la herramienta hay campos obligatorios sin valor, se
mostrará el mensaje correspondiente y se procederá como si de un
usuario nuevo se tratara (para esa herramienta). El formulario no
permitiría guardar cambios hasta que la información obligatoria
fuera completamente rellena.
CRUD de Usuarios: Borrado de Usuario
Además, el formulario de edición de usuario incluirá, para los
usuarios autorizados, un check para el borrado de los mismos que
realizará la llamada a los respectivos deleteUser de cada aplicación,
previa confirmación.
Figura 4.9 – Borrado de usuarios
38

39. 4.4.2.
Gestión de Roles
Los roles de cada usuario se mostrarán divididos (en pestañas
o
en
secciones
del
formulario)
según
cada
aplicación.
La
actualización de roles se producirá por aplicación, de modo que cada
aplicación montará su propio formulario de gestión de roles.
Si una aplicación no devuelve ningún rol en su petición de
roles, no tendrá sección en el formulario.
En general, el formulario de asignación de roles se compondrá
usando tres funciones, una que devuelva los roles disponibles de la
herramienta, otra que devuelva los ámbitos, y una última que
devuelva las asignaciones de rol y ámbito que ya tiene el usuario.
Si la gestión de roles no se ajusta a este sistema (por incluir
más características), usará una función que devuelva un formulario
propio.
39

40. Figura 4.10 – Detalle de perfil
40

41. Gestión de Roles en Drupal
Drupal
no
tiene
ámbitos
como
tales,
y
tampoco
tiene
modificadores de ámbito.
El formulario de Drupal se realizaría con el mantenimiento
genérico.
Gestión de Roles en GLPI
GLPI tiene ámbitos, que se identifican con las Entidades.
También tiene un modificador que es el de la recursividad, así que lo
apropiado sería que devolviera su propio formulario de gestión de
roles.
Gestión de Roles en Alfresco
Alfresco tiene ámbitos, que se identifican con los espacios.
También tiene un modificador que es el de la recursividad, así que lo
apropiado sería que devolviera su propio formulario de gestión de
roles.
Gestión de Roles en dotProject
dotProject no tiene ámbitos como tales, y tampoco tiene
modificadores de ámbito.
El formulario de dotProject se realizaría con el mantenimiento
genérico.
Gestión de Roles en Moodle
Moodle tiene ámbitos, que se identifican con los cursos.
El formulario de Moodle se realizará con el mantenimiento
genérico.
41

42. 4.4.3.
Consideraciones adicionales
Para preservar la integridad de los datos, lo adecuado sería
que la administración de usuarios de cada herramienta estuviera
reservada
únicamente
para
los
usuarios
de
perfil
super-
administrador, o directamente anulada. Como esto no será posible
en todas las circunstancias, por eliminar funcionalidades deseadas,
siempre habrá que contemplar la prioridad de la propia herramienta
de Gestión Integral de Usuarios sobre las demás, y que los datos que
prevalecerán siempre serán los de las herramientas configuradas
como tal.
Una posible configuración sería con LDAP, DRUPAL, GLPI y
Alfresco, configurados en la herramienta de Gestión Integral de
Usuarios, en la que un usuario con privilegios modificara una
información directamente en la aplicación de GLPI. Cuando se
cargara el formulario de edición de datos, los atributos coincidentes
entre
las
herramientas
LDAP,
DRUPAL
y
GLPI,
siempre
prevalecerían los de las dos primeras sobre la última.
Por cada Aplicación:
 listUsers
 getAttributes
 createUser
 deleteUser
 getFieldValue
 getFieldValidation
 setFieldValue
42

43.  getRoles
 getScopes
 grantRole
 revokeRole
Para la Gestión de Usuarios:
 listUsers
 getAttributes
 getApps
 createUser
 deleteUser
 getAttributeValue
 getAttributeValidation
 setAttributeValue
 showRoleForm
43

44. 5.Diseño del Sistema
5.1.
Introducción
En el presente apartado de la documentación se describe el
diseño que se ha realizado de los módulos del sistema, así como la
arquitectura que el sistema de gestión de contenidos Drupal
proporciona.
5.2.
Arquitectura de Drupal
Drupal es un Sistema de Gestión de Contenidos (CMS) cuya
lógica
está
programada
en
PHP,
siguiendo
un
modelo
de
programación estructurada, y que hace uso de un sistema de bases
de datos relacional.
Figura 5.1 - Esquema de la arquitectura de Drupal [9]
El código que constituye el núcleo de Drupal está formado por
un conjunto de librerías que permiten gestionar los procesos de
arranque del sistema. Estas librerías ofrecen además un conjunto de
servicios que permiten integrar las funcionalidades adicionales de
los módulos, servicios como conexión y administración de la base de
datos, gestión de procesos de mailing, tratamiento de imágenes,
internacionalización, soporte para la codificación y un potente
entorno de integración de utilidades. Este último servicio, que
44

45. explicaremos a continuación, permite ampliar las funcionalidades de
un sistema Drupal de una forma relativamente sencilla.
Drupal es, por tanto, un sistema con una arquitectura modular
que permite ampliar sus funcionalidades a través de unos métodos
uniformes de desarrollo e integración de nuevos módulos. En última
instancia un módulo consiste en un conjunto de archivos con código
PHP, que utiliza la arquitectura y las APIs de Drupal para incorporar
nuevas características funcionales al sitio web [9].
5.2.1.
Módulos
Drupal
proporciona
los
módulos
para
extender
su
funcionalidad. La funcionalidad que proporcionan los módulos puede
ser habilitada o deshabilitada a través de la correspondiente página
de administración.
Drupal consigue proveer esta funcionalidad gracias a la
implementación que realiza del patrón de diseño “Inversion of
Control”, este patrón de diseño consiste en un cambio en el flujo de
ejecución de un programa en el que en vez de especificar el flujo de
la información se especifica la respuesta esperada de una operación.
Figura 5.2 - Inversion of Control [10]
De esta forma los nuevos módulos que se añaden a Drupal se
disponen de la siguiente forma dentro del core de Drupal.
45

46. Figura 5.3 – Estructura de módulos [11]
Así mismo Drupal proporciona “themes” que permiten la
personalización de la apariencia del sitio web para adaptarlo a la
entidad corporativa de la empresa con la que se está trabajando, de
esta forma se consigue obtener un portal totalmente adecuado y
personalizado a las necesidades del cliente.
5.2.2.
El
Drupal y MVC
modelo-vista-controlador
(MVC)
es
un
patrón
de
arquitectura de software que separa los datos de una aplicación, la
interfaz de usuario, y la lógica de control en tres componentes
distintos. El patrón MVC se ve frecuentemente en aplicaciones web,
donde la vista es la página HTML y el código que provee de datos
dinámicos a la página. El modelo es el SGBD y el controlador es el
responsable de recibir los eventos de entrada desde la vista.
•
Modelo:
Esta
es
la
representación
específica
de
la
información con la cual el sistema opera. La lógica de datos
asegura la integridad de estos y permite derivar nuevos
datos.
46

47. •
Vista: Este presenta el modelo en un formato adecuado
para interactuar, usualmente la interfaz de usuario.
•
Controlador:
Este
responde
a
eventos,
usualmente
acciones del usuario e invoca cambios en el modelo y
probablemente en la vista.
Figura 5.4 – MVC [12]
En Drupal este patrón arquitectónico está implementado de la
siguiente forma:
Figura 5.5 - Patrón arquitectónico MVC
Como se puede observar en la utilización que Drupal hace del
patrón arquitectónico MVC no existe interacción entre la vista y el
modelo, esto se debe a que dichas interacciones siempre se realizan
a través de la lógica de negocio, el controlador.
47

48. 6.Diseño de datos
Pasamos ahora a la elaboración de la capa de persistencia del
sistema.
Independientemente
del
SGBD
empleado
finalmente,
necesitamos un Modelo de Datos que represente los aspectos
estáticos y dinámicos del Modelo del Dominio de uestro Portal Web.
Existen muchos tipos de Modelos de Datos, pero el de más alto
nivel
y
mayor
facilidad
de
comprensión
son
los
modelos
conceptuales, con conceptos muy cercanos al Modelo del Dominio (y
al modelo de clases obtenido en el análisis).
Uno de los modelos de alto nivel más empleados es el
denominado Diagrama Entidad - Relación, el cual usaremos para
describir nuesta Base de Datos final de una forma más general y
expresiva. La razón de utilizar un modelo de tan alto nivel nos
permite independizarnos de la implementación final escogida.
6.1.
Diagrama Entidad - Relación del
Sistema
En los diagramas Entidad - Relación, las clases del Modelo del
Dominio se convierten en entidades, las cuales se relacionan
mediante una serie de asociaciones que definen una serie de
información relevante para el sistema.
De la información extraida del diagrama de clases del análisis,
obtenemos el siguiente esquema conceptual de datos, considerando
los siguientes aspectos:
1. Para cada entidad indicaremos la clave primaria (PK) de la
tabla final que representará dicha entidad.
48

49. 2. Para cada relación, la cardinalidad se expresa mediante el
esquema X:Y, siendo X e Y la multiplicidad mínima y
máxima de cada entidad que participe en la relación.
A continuación vemos el diagrama de nuestro sistema:
Diagrama entidad-relación
Figura 6.1 - Diagrama entidad-relación
49

50. 6.2.
Entidades del Modelo de Datos
Las entidades que utilizaremos en nuestro modelo serán las
siguientes:
GIU_USERS
Atributo
Tipo
Nulo?
Predet.
PK
Autoinc.
X
Nulo?
Predet.
PK
Autoinc.
X
id
tinyint(4)
No
name
varchar(100)
No
email
varchar(255)
FK
No
Tabla 6.1 - GIU_USERS
GIU_PROFILES
Atributo
Tipo
id
int(10)
No
name
varchar(255)
No
description
varchar(255)
FK
Si
Tabla 6.2 - GIU_PROFILES
GIU_USERS_PROFILES
Atributo
Tipo
Nulo?
Predet.
PK
Autoinc.
FK
X
id
int(10)
No
user_id
int(10)
No
X
profile_id
int(10)
No
X
Tabla 6.3 - GIU_USERS_PROFILES
50

51. GIU_ENVIRONMENT_PROFILES
Atributo
Tipo
Nulo?
Predet.
PK
Autoinc.
X
id
int(10)
No
profile_id
int(10)
No
moodle
text
No
glpi
text
No
Ocs
text
No
dotproject
text
No
alfresco
text
No
drupal
text
FK
No
X
Cuadro 6.4 – GIU_ENVIRONMENT_PROFILES
51

52. 6.3.
Relaciones del Modelo de Datos
Entidades
Cardinalidad
Descripción
giu_users
1:1
Un usuario tiene un sólo perfil
giu_users_profiles
Tabla 6.5 – Relaciones del modelo de datos
Entidades
Cardinalidad
giu_profiles
1:N
giu_users_profiles
Descripción
Un perfil puede estar asociado a
más de un usuario
Tabla 6.6 - Relaciones del modelo de datos
Entidades
Card.
giu_profiles
1:1
gui_environment_profiles
Descripción
Un perfil tiene una sola configuración
de permisos
Tabla 6.7 - Relaciones del modelo de datos
52

53. 7.Codificación
7.1.
Entorno de programación y
Herramientas
Drupal está diseñado para funcionar sobre, prácticamente,
cualquier
entorno
independientemente
del
sistema
operativo,
servidor web o sistema de gestión de base de datos.
Figura 7.1 – Entornos
Además Drupal proporciona un framework responsable de
proveer las funcionalidades básicas necesarias en las otras partes
del sistema, así como de servir de soporte para las nuevas
funcionalidades.
53

54. En nuestro caso haremos uso de las siguientes herramientas:
Elemento
Tipo
Hardware
Detalle
PC
Versión
Sony VAIO
Sistema Operativo
Entorno de desarrollo
Ubuntu 12.04
NetBeans
7.3
Apache
2.2.22
extensión PHP
mysqli
SGBD
MySQL
5.5.31
Gestión Web BD
phpMyAdmin
Servidor Web
Software
3.4.10.1deb1
Firefox
21.0
Navegadores
Chromium
25.0.1364.16
Tabla 7.1 – Herramientas usadas
7.2.
Lenguajes de programación
PHP
PHP es un lenguaje de programación interpretado, diseñado
originalmente para la creación de páginas web dinámicas. Es usado
principalmente
en
interpretación
del
lado
del
servidor,
pero
actualmente puede ser utilizado desde una interfaz de línea de
comandos o en la creación de otros tipos de programas incluyendo
aplicaciones con interfaz gráfica.
PHP es un acrónimo recursivo que significa PHP Hypertext
Pre-processor (inicialmente PHP Tools, o, Personal Home Page
Tools). Fue creado originalmente por Rasmus Lerdorf en 1994; sin
embargo la implementación principal de PHP es producida ahora por
The PHP Group y sirve como el estándar de facto para PHP al no
haber una especificación formal. Publicado bajo la PHP License, la
54

55. Free Software Foundation considera esta licencia como software
libre.
AJAX
Ajax,
acrónimo
de
Asynchronous
JavaScript
And
XML
(JavaScript asíncrono y XML), es una técnica de desarrollo web para
crear aplicaciones interactivas o RIA (Rich Internet Applications).
Estas aplicaciones se ejecutan en el cliente, es decir, en el
navegador de los usuarios mientras se mantiene la comunicación
asíncrona con el servidor en segundo plano. De esta forma es posible
realizar cambios sobre las páginas sin necesidad de recargarlas, lo
que significa aumentar la interactividad, velocidad y usabilidad en
las aplicaciones.
Ajax es una tecnología asíncrona, en el sentido de que los
datos adicionales se requieren al servidor y se cargan en segundo
plano sin interferir con la visualización ni el comportamiento de la
página. JavaScript es el lenguaje interpretado (scripting language)
en el que normalmente se efectúan las funciones de llamada de Ajax
mientras
que
el
acceso
a
los
datos
se
realiza
mediante
XMLHttpRequest, objeto disponible en los navegadores actuales. En
cualquier caso, no es necesario que el contenido asíncrono esté
formateado en XML.AJAX
HTML
HTML, siglas de HyperText Markup Language (Lenguaje de
Marcado de Hipertexto), es el lenguaje de marcado predominante
para la elaboración de páginas web. Es usado para describir la
estructura y el contenido en forma de texto, así como para
complementar el texto con objetos tales como imágenes. HTML se
escribe en forma de "etiquetas", rodeadas por corchetes angulares
(<,>). HTML también puede describir, hasta un cierto punto, la
55

56. apariencia de un documento, y puede incluir un script (por ejemplo
Javascript), el cual puede afectar el comportamiento de navegadores
web y otros procesadores de HTML.
HTML también es usado para referirse al contenido del tipo de
MIME text/html o todavía más ampliamente como un término
genérico para el HTML, ya sea en forma descendida del XML (como
XHTML 1.0 y posteriores) o en forma descendida directamente de
SGML (como HTML 4.01 y anteriores).
JAVASCRIPT
JavaScript es un lenguaje de scripting basado en objetos,
utilizado para acceder a objetos en aplicaciones. Principalmente, se
utiliza integrado en un navegador web permitiendo el desarrollo de
interfaces de usuario mejoradas y páginas web dinámicas. JavaScript
es un dialecto de ECMAScript y se caracteriza por ser un lenguaje
basado en prototipos, con entrada dinámica y con funciones de
primera clase. JavaScript ha tenido influencia de múltiples lenguajes
y se diseñó con una sintaxis similar al lenguaje de programación
Java, aunque más fácil de utilizar para personas que no programan.
Todos
los
navegadores
modernos
interpretan
el
código
JavaScript integrado dentro de las páginas web. JavaScript se
ejecuta en el agente de usuario, al mismo tiempo que las sentencias
van descargándose junto con el código HTML.
56

57. 7.3.
Otros aspectos relevantes de la
implementación
A continuación mostraremos lo más reseñable de nuestra
aplicación.
Lo primero que vamos a destacar es la conexión a las
aplicaciones, donde todas las acciones que hacemos en el sistema
deben crear una conexión.
Para ello usaremos esta sentencia por cada una de las
aplicaciones que queremos conectarnos:
Guardamos la conexión en una variable de Drupal.
57

58. Lo siguiente que vamos a destacar es la creación del listado de
usuarios:
58

59. ...
59

60. 60

61. Con esta función nos traemos los campos que nos interesan de
cada aplicación, cada una de las aplicaciones con la que queramos
interactuar tiene su propia función init:
61

62. También tenemos una función que valida los campos para que
no haya errores a la hora de trabajar con cada una de las DB de cada
aplicación:
62

63. 8.Conclusiones
Una vez finalizado el proyecto, se puede concluir que el
módulo para la gestión de usuarios cumplirá con las expectativas,
reduciendo el coste que supone dar de alta a un mismo usuario en
todas las aplicaciones de forma individual.
La solución de integración de las diferentes aplicaciones en un
módulo para realizar la gestión en Drupal supone una facilidad para
las futuras altas de usuarios por parte del administrador.
La gestión de usurios ha sido el tema en este proyecto pero ha
quedado bien resuelta con la solución planteada e implementada.
Delegar el almacenamiento de los usuarios a un directorio LDAP,
facilita
notablemente la gestión de estos, ya que este tipo de
directorio está muy extendido para este uso.
También el uso de un “Single Sign On” como CAS es acertado,
por disponer de conectores
en casi todos los lenguajes de
programación en entorno web existente. Pese a existir alternativas
como la autenticación por medio de OpenID o Facebook, creo
firmemente que es mucho mejor esta solución al no perder el control
de los usuarios en ningún momento, mientras que si se delega a ese
tipo de herramientas, se deja de controlar.
La filosofía de este proyecto, en que todas las aplicaciones
tienen un origen OpenSource, es un modelo que me parece también
acertado. No solo por estar imponiéndose y resultar más económico
para las empresas, sino por el resultado final de los proyectos.
Este proyecto finaliza en un punto donde la plataforma puede
ser suficiente para un gran número de empresas. Pero la posibilidad
de
integrar
herramientas
más
específicas
para
determinadas
63

64. funciones, puede resultar del interés de empresas grandes, sobre
todo si ya disponen de estas.
64

65. 9.Glosario de términos
Navegador o navegador web: (del inglés, web browser) es un
programa que permite visualizar la información que contiene una
página web (ya esté está alojada en un servidor dentro de la World
Wide Web o en uno local).
Base de datos: es un conjunto de datos pertenecientes a un mismo
contexto y almacenados sistemáticamente para su posterior uso. En
la actualidad, y debido al desarrollo tecnológico de campos como la
informática y la electrónica, la mayoría de las bases de datos están
en formato digital (electrónico), que ofrece un amplio rango de
soluciones al problema de almacenar datos.
Login: es el acto de establecimiento o confirmación de algo (o
alguien) como auténtico, es decir que reclama hecho por, o sobre la
cosa son verdadero. La autenticación de un objeto puede significar
(pensar) la confirmación de su procedencia, mientras que la
autenticación de una persona a menudo consiste en verificar su
identidad.
Scrum: Es una metodología de trabajo ágil para la gestión de
proyectos.
Directorio LDAP: Directorio para almacenar información en red,
como usuarios o listín telefónico.
Single Sign On: Sistema de autenticación unificado para varias
aplicaciones.
OpenLDAP: Producto OpenSource que implementa un directorio
LDAP.
65

66. 10. Referencias
[1] PALACIO, Juan. Flexibilidad con Scrum.
http://www.scribd.com/doc/48689944/Flexibilidad-con-Scrum
[2] SCRUM, Org. La guía de Scrum
http://www.scrum.org/
[3] ALBALADEJO, Xavier. Que es Scrum?
http://wpww.royectosagiles.org/que-es-scrum
[4] SCRUMALLIANCE
http://www.scrumalliance.org/pages/who_uses_scrum
[5] SCRUM, Org. La guía de Scrum
http://www.scrum.org/storage/scrumguides/Gua%20sobre
%20Scrum.pdf#view=fit
[6] SCRUMALLIANCE – What is scrum?
http://www.scrumalliance.org/pages/what_is_scrum
[7] CAS – Universidad de yale CAS
http://www.jasig.org/cas
[8] DONNELLY, Brian – CAS
https://confluence.ucdavis.edu/confluence/display/IETP/About+CA
S
[9] Libros Aprende Drupal
http://www.forcontu.com/libros-drupal7
[10] http://en.wikipedia.org/wiki/File:Inversion_of_Control.svg
[11] koala-soft
http://www.koala-soft.com/drupal
[12] Programación Cocoa
http://luisrey.wordpress.com/2008/01/13/modelo-vistacontrolador/
66

67. [13] OPENLDAP
http://www.openldap.org/
[14] XPLORER
http://jxplorer.org/
67

68. 11. Bibliografía
•
FORCONTU
o
•
http://www.forcontu.es/
Estudio de los sistema de gestión de contenidos web (CMS)
o
http://www.opencmshispano.com/nav/noticias/noticia_01
05.html
•
BUTCHER, Matt - Learning Drupal 6 Module Development
•
TIMOTHY, A Howes - Understanding and Deploying LDAP
directory Services
•
APACHE, httpd – Servidor web apache2
o
•
PHP5
o
•
http://httpd.apache.org/
http://www.php.net/
APACHE, tomcat – Servidor Java
http://tomcat.apache.org/
•
DRUPAL
http://drupal.org/
68