PEP (Policy Enforcement Point)

El PEP o “Policy Execution Point” es el encargado de ejecutar las acciones del PDP. Por razones de consistencia tanto el PDP como PEP están implementados en Java. Las funciones del PEP son ejecutar las acciones en cada uno de los recursos que forman parte del sistema, esto quiere decir, el entorno “web”, las bases de datos “SQL” y el establecimiento de las comunicaciones entre equipos, refiriéndose a la utilización de servidores DNS para identificar servidores de contenidos y al uso del protocolo Kerberos para el intercambio de información por canales seguros.

El PEP en realidad está formado por un conjunto de PEP más reducidos. Desde el punto de vista lógico de nuestro sistema ya hemos comentado la existencia de un PDP y un nivel más inferior la existencia del PEP. No obstante el PEP según su funcionalidad está distribuido, es decir, se diferencian las acciones a realizar según el entorno “web”, bases de datos “SQL” y canales de comunicación entre gestor y servidores de contenidos.

Así tenemos en primera instancia que se ha desarrollado un PEP capaz de cursar las acciones “web”, tales acciones son las ya expuestas en el conjunto de políticas LDAP. Este primer PEP utiliza la interfaz de comunicación implementada con el uso de la tecnología “JavaBeans” con el nivel superior. Básicamente las funciones del PEP de la interfaz “web” responden al control de sesiones y manipulación de las consultas URL.

Cuando se recibe una consulta “web” desde las páginas JSP se extraen los parámetros de las consultas y los datos de sesión almacenados de las consultas anteriores o

únicamente los parámetros de las consultas en caso de no haber todavía una sesión definida. Toda esta información es enviada el PDP quien responde con las acciones a realizar.

Las posibles acciones son “añadir datos de sesión”, “mostrar las páginas solicitadas” o redireccionar la consulta a páginas de error; debido a elecciones incorrectas por el

usuario, a accesos no autorizados según el control de acceso, etc.

4.8.1. PEP Web

A nivel “web” Las acciones del PEP son implementadas directamente en las páginas JSP.

Las páginas JSP integran el código “html” y acciones PEP. Estas paginas están agrupadas básicamente en tres secciones.

La primera sección recoge los parámetros de la consulta URL. A éstos se les unen los datos almacenados en la sesión. Toda esta información es almacenada en un objeto java destinado a albergar toda la información que se intercambian PDP y PEP.

La segunda sección corresponde a la solicitud PDP. Éste recogerá los datos y dará una respuesta.

Mediante el análisis de la respuesta y “mapeos” según el vocabulario del sistema, el PEP descodificará la respuesta e invocará la orden a ejecutar.

Tanto la primera sección como la segunda sección hacen uso de la tecnología “JavaBeans” para la comunicación entre JSP y los objetos Java.

Finalmente la tercera sección es la ejecución de las órdenes. Éstas pueden ser, manipular los datos de sesión, redireccionar las consultas y/o incluir código “html”.

4.8.2. PEP SQL

Las acciones a realizar sobre las bases de datos se clasifican en dos tipos, según a qué máquina van dirigidas. Por una parte tenemos las consultas que actualizan la base de datos local del gestor de nuestro sistema. Esta base de datos contiene todas las tareas a realizar de todos los servidores de contenidos. La otra posibilidad es actualizar las bases de datos de los servidores de contenidos, estas bases de datos no se encuentran en la propia maquina gestora, por ello se deben realizar el intercambio de información por medios seguros, es aquí cuando intervendrán los servicios DNS y el protocolo Kerberos.

En lineas generales el gestor y los servidores de contenidos tienen una base de datos “SQL” con las tareas a realizar. Por cada solicitud de adquisición de contenidos por parte de un usuario, cursada correctamente, el PDP comunica con un PEP destinado

únicamente a la actualización de bases de datos SQL.

Este PEP dedicado a SQL constituye el segundo PEP de nuestro conjunto global.

Desde los objetos Java se utiliza el “mysql-connector” para actualizar dos bases de datos. La primera es la base de datos del propio gestor que mantendrá para posteriores consultas las tareas pendientes, las que se están realizando y las ya realizadas de todos los servidores de contenidos, de este modo fácilmente y sin tener que lanzar consultas por la red, atacando directamente a los servidores de contenidos podrá disponer en todo momento de un fuente de información para la decisión de las consultas de los usuarios web.

La otra base de datos es utilizada para almacenar las consultas pendientes de ser enviadas a los servidores de contenidos.

A lo largo del presente desarrollo de este proyecto se propuso que para cada solicitud de adquisición de contenidos, cursada correctamente según las políticas, se actualizaba la base de datos de los servidores de contenidos. No obstante estas consultas son más costosas en cuanto al establecimiento de los canales seguros de comunicación que a la información útil propiamente dicha. Por ello, con intención de mejorar la eficiencia, el sistema recoge todas las consultas y únicamente las actualiza cada cierto intervalo de tiempo, en concreto cada minuto. Con ello es utilizada una única comunicación con cada servidor de contenidos implicado para la actualización de todas las nuevas tareas a realizar.

Un caso distinto es cuando se producen eventos entre los servidores de contenidos y los clientes “video streaming”, tales eventos pueden ser el inicio de la distribución del contenido, finalización o errores. En tales situaciones los servidores de contenidos informan inmediatamente el gestor para que tome las decisiones oportunas.

Así entonces tenemos que las consultas son almacenadas en las bases de datos del gestor y cada cierto intervalo de tiempo se envían a los servidores de contenidos. El envío de la información hacia los servidores de contenidos formaría parte del tercer PEP.

4.8.3.­ Actualización tareas servidores de contenidos

El sistema dispone de un programador de tareas implementado mediante “perl”. Cierto es que todos los sistemas Unix, BSD y GNU/Linux disponen de la herramienta “cron” precisamente para la programación de tareas. No obstante se decidió ofrecer un sistema implementado propio para poder aumentar la independencia de nuestra solución del sistema.

En esta sección se ha utilizado el lenguaje “perl” para la implementación de los

programas por diferentes motivos. El primero de ellos es que es un lenguaje que ofrece "portabilidad" entre sistemas, ya que se compila el código durante la ejecución del mismo. Perl además de un lenguaje de programación es en realidad un intérprete de comandos y existe para todas las plataformas, incluidas Unix, BSD, GNU/Linux, Mac OS y Windows. Es muy cómodo para la implementación de pequeños programas, con muy pocas lineas de código pueden implementarse cualquier funcionalidad. Finalmente pese a sus

alternativas “bash”, “python”, etc. tiene un nivel de eficiencia muy superior a sus competidores.

A grandes rasgos el algoritmo es el siguiente. El proceso de programación de tareas ejecuta un pequeño programa cada minuto. Este programa realiza el establecimiento de un canal seguro para transmitir la información entre gestor y servidor de contenidos, se actualizan las bases de datos y finalmente de un modo análogo que en el gestor, existe un programador de tareas en los servidores de contenidos que según las entradas de las bases de datos publican o eliminan los contenidos de los servidores.

Podemos por tanto resumir este último “PEP” como el conjunto de tres programas. El primero de ellos el “programador de tareas” del gestor, el segundo el responsable de establecer el “canal seguro de comunicación”, el tercero el que “actualiza las bases de

datos SQL” de los servidores de contenidos y finalmente el cuarto es el “programador de tareas de los servidores” de contenidos.

4.8.4. Canal seguro de comunicación

El canal seguro de comunicación se establece automáticamente mediante aplicaciones que permiten una comunicación cliente-servidor que integran el protocolo Kerberos.

El MIT, responsable de la creación del protocolo de Kerberos, difundió en su día varios servicios unix que integraban su protocolo de seguridad. Estos servicios unix son “telnet”, “rsh”, “ssh”, “kshell” entre otros. Configurados correctamente establecen una

comunicación segura entre clientes y servidores de un modo totalmente transparente para el usuario. Hoy día prácticamente todas las soluciones Unix, BSD y GNU/Linux.

Los servicio “unix” antes mencionados están diseñados para la interacción con un usuario, esperando un conjunto de entrada y salida que exige la interpretación de una persona y sin embargo nosotros los utilizamos de una manera totalmente automatizada. Ello es conseguido gracias al uso de una herramienta disponible en cualquier sistema Unix y variantes cuyo nombre es “expect”.

Expect es una herramienta que permite mediante una cierta sintaxis programar cualquier ejecución de comandos unix y actuar en función de la respuesta obtenida. En realidad se trata de un emulador de la interacción de una persona con el sistema.

El programa encargado de establecer el canal seguro en realidad invoca a un programa “expect” que es el que lanza el cliente “telnet” y así establecer el canal, para después lanzar las instrucciones “SQL” en las máquinas servidores de contenidos como si fueran consultas locales.

Evidentemente tanto cliente como servidor “telnet” deben configurarse correctamente para el uso del protocolo Kerberos.

El cliente “telnet”, que integra el protocolo kerberos, resuelve mediante DNS la IP de los servidores de contenidos e inmediatamente lanza una consulta contra el servidor

“kerberos”, solicitando una comunicación segura con tales servidores. En esta sección no comentamos cuál es el funcionamiento exacto en del protocolo kerberos ya que existe una dedicada completamente a ello. Para nosotros lo importante aquí es el uso del servicio DNS para conocer las IPs de las máquinas que intervienen, tanto los servidores de contenidos como el servidor Kerberos apoderado del dominio y así poder utilizar una simple sesión remota contra los servidores para actualizar las bases de datos.