Soporte multicentro

Hola a todos,

Antes de nada aprovechamos la ocasión para mostrar una captura (muy) provisional del aspecto que tendrá la portada de ÁTICA. En ella se mostrará toda la información marcada de acceso público, por ejemplo la misión del centro o los criterios de evaluación y corrección. Esto es un avance respecto al acceso de invitados que había previamente y del que hablaremos dentro de poco.

Hoy volvemos a la carga, esta vez para explicar un aspecto muy importante que una aplicación como ÁTICA debe cumplir: el soporte multicentro. Para ello, vamos a echar mano de la experiencia acumulada con otras versiones.

Introducción y motivación

Hasta ahora, el modelo de datos de ÁTICA sólo soportaba un único SGC y, por tanto, un único centro educativo. La razón es que la aplicación se concibió para ser instalada de forma individual, pues no había muchos centros interesados en su implantación en un primer momento.

Sin embargo, con el tiempo, el grupo de trabajo de ÁTICA ha ido añadiendo en su seno más centros. De hecho, actualmente está formado por tres: I.E.S. Ntra. Sra. de la Cabeza (Andújar), I.E.S. Oretania (Linares) e I.E.S. Pablo de Olavide (La Carolina). Esto ha creado una nueva necesidad: la de mantener actualizadas tres plataformas separadas, tarea que, de hecho, no resulta fácil. La prueba es que hemos necesitado varios meses para poder poner en funcionamiento la misma versión en los tres sitios. Además, antes de realizar el despliegue de cada cambio es necesario realizar una serie de pruebas que prevengan (en lo posible) problemas con la nueva funcionalidad.

Una posible solución pasaría por compartir el mismo código de la aplicación para todas las plataformas. Así, cualquier cambio se reflejaría instantáneamente en todos los centros, independientemente de su número. Por eso, la nueva versión de ÁTICA lleva el soporte multicentro implantado desde la médula. A este concepto se le conoce como multi-tenancy en el mundo de la arquitectura software.

Ventajas:

• Dar soporte a una única instancia facilita el despliegue de actualizaciones.
• Las copias de seguridad pueden ahora ser centralizadas. Además, se pueden tomar medidas adicionales para aumentar la disponibilidad del servicio, como sistemas de alimentación ininterrumpida o conexiones de red redundantes en un único servidor y se beneficiarían todos los centros.
• Se puede compartir información entre varios centros educativos, como por ejemplo, los usuarios.

Inconvenientes:

• Complica un poco el modelo de datos interno que usa la aplicación, pues ahora hay que distinguir a qué centro u organización pertenece cada aspecto.
• La seguridad debe reforzarse para evitar que documentos de una organización sean accesibles desde otra por personal no autorizado.
• Un fallo de despliegue afectará a todas los centros alojados en la instancia. Antes, si el despliegue de un centro fallaba no se aplicaba la actualización a los demás hasta localizar el problema.

Aún así, lo mejor de esta característica es que permite mantener el modelo anterior de una instancia por centro sin problema alguno, en cuyo caso la mayoría de los inconvenientes se esfuman. Por tanto, es mucho más flexible.

Detalles técnicos

Aparte de los cambios en el modelo de datos, hay otros aspectos técnicos que hemos tenido que resolver. Aquí comentamos algunos de ellos:

¿Cómo se realiza la gestión de usuarios?

Los usuarios son compartidos para todos los centros educativos. Eso quiere decir que un usuario puede formar parte de cualquier número de ellos, pero siempre tendrá el mismo nombre de usuario y contraseña. Para «homogeneizar» el acceso se ha decidido recomendar que el nombre de usuario sea su usuario IdEA pues todos el personal de los centros educativos de la Consejería de Educación de la Junta de Andalucía tiene uno.

Como es lógico, cuando acceda el usuario a cada centro sus perfiles podrán ser (y seguramente serán) distintos.

¿Cómo y quién administra la aplicación?

Ahora se distinguen dos tipos de administradores: el administrador general y el administrador local. El primero se asigna manualmente a uno o varios usuarios y podrá crear/eliminar instancias o realizar cambios que afecten a todos los centros. Lógicamente, debe restringirse su uso lo máximo posible.

Por otro lado, el administrador local está asociado a un perfil especial, como por ejemplo el de «Coordinador/a de Calidad» o el de «Director/a». Todos aquellos usuarios que tengan ese perfil en un centro dado podrán realizar cambios que afecten solamente a dicho centro. Algunas de sus tareas típicas implican la creación del árbol documental o la gestión de usuarios.

Se ha estudiado la seguridad de este modelo para evitar ciertos tipos de ataque.

Por ejemplo: «Un administrador local podría añadir a su centro a un administrador general y, una vez es usuario de su centro, cambiar su contraseña a una conocida. A partir de ahí, sólo tendría que salir y volver a entrar como el usuario suplantado para tener permisos de administrador general».

Por ello se ha decidido restringir el cambio de contraseñas en algunos casos. Por ejemplo: un administrador local puede cambiar cualquier contraseña de un usuario de su centro salvo que dicho usuario sea administrador general o pertenezca a un perfil de administrador local en algún otro centro. Esto elimina muchos riesgos potenciales. Un administrador general no tiene esas limitaciones.

¿Cómo facilitamos que los usuarios accedan al centro correcto?

Se han barajado varias posibilidades:

• Reconocer el centro por la URL desde la que se intenta acceder a la aplicación. De esta forma se pueden usar registros CNAME que apunten al mismo servidor y la aplicación distinguirá el centro. Un ejemplo no-técnico: se puede configurar que «atica.iesoretania.es» y «atica.iescabeza.es» apunten al mismo servidor web. Cada vez que se reciba una solicitud, se comprueba a cuál de los dos nombres se refiere el navegador y da acceso directo al centro correspondiente.
• Añadir un parámetro a la dirección de entrada a la página web que distinga entre un centro y otro. Por ejemplo: si el usuario pincha un enlace que apunte a «www.atica.org.es/?o=1» se entra en un centro y si el enlace contiene «www.atica.org.es/?o=2», le lleva a otro.
• Si no hay información suficiente para distinguir de primeras a qué centro quiere ir el usuario, se puede mostrar un menú para que lo elija manualmente.

• Se accede siempre a la misma dirección y la aplicación analiza si la petición de conexión procede de la Red Corporativa de la Junta de Andalucía para intentar deducir de qué centro viene. El problema de esta opción es que impide que un usuario pueda acceder a la instalación de otro centro, pues siempre se le redirigirá a aquel donde se encuentra.

Todas ellas están implementadas actualmente salvo la última, que aún está en estudio.

Conclusiones

La nueva característica aporta flexibilidad a ÁTICA y permite instalarla en un sitio centralizado para dar servicio a más de un centro simultáneamente, simplificando la administración, facilitando el despliegue de actualizaciones y reduciendo el tiempo entre que se detecta un problema y se soluciona en todos los centros.

La próxima entrada tratará un problema que suelen sufrir las aplicaciones web modernas: cómo soportar que los motores de búsqueda indicen los contenidos públicos de forma correcta. ¡Hasta la próxima!