Diseño e implementación de una Arquitectura RBAC basada en Servicios Web

UNIVERSIDAD NACIONAL DEL COMAHUE
FACULTAD DE ECONOMA Y ADMINISTRACIN

DEPARTAMENTO DE CIENCIAS DE LA COMPUTACIN
TESIS PARA LA CARRERA LICENCIATURA EN CIENCIAS DE LA COMPUTACIN Diseo e implementacin de una Arquitectura RBAC basada en Servicios Web
Matas Eloy Salcedo
Jorge Eduardo Sznek
NEUQUN Junio 2011
ARGENTINA
PGINA PARA LOS EVALUADORES

Calificacin:
Comentarios:
..
....
Lugar para la Fecha de la Evaluacin
III
DEDICATORIAS
Quisiera dedicar este trabajo a mi familia, por el gran apoyo que pacientemente me brindaron durante el tiempo de desarrollo de la tesis. A Brenda por ser mi sostn incondicional, por darme fuerzas da a da para continuar, con su cario, entrega y amor. Y a todas aquellas personas que siempre estuvieron conmigo apoyndome y brindndome todo su cario.
IV
PREFACIO
Esta tesis es presentada como parte de los requisitos finales para optar al grado acadmico Licenciado en Ciencias de la Computacin, de la Universidad Nacional del Comahue y no ha sido presentada previamente para la obtencin de otro ttulo en esta Universidad u otras. La misma es el resultado de una investigacin llevada a cabo en el Departamento de Ciencias de la Computacin en el perodo comprendido entre Diciembre de 2008 y junio de 2011, bajo la direccin de Jorge Eduardo Sznek
Matas Eloy Salcedo DEPARTAMENTO DE CIENCIAS DE LA COMPUTACIN UNIVERSIDAD NACIONAL DEL COMAHUE Neuqun, . de Junio de 2011.
AGRADECIMIENTOS
Primero quisiera expresar mis agradecimientos a mi director de tesis, Jorge Eduardo Sznek, por su gua, esfuerzo y dedicacin durante todo el proyecto de tesis. Tambin a todos los profesores que he tenido durante la carrera, cada uno de ellos ha dado su mejor esfuerzo brindndome no solo el conocimiento necesario para mi formacin como profesional sino tambin sus experiencias, motivaciones, ejemplos y concejos que han acrecentado mi formacin como persona. A todos ellos muchas gracias.
VI
RESUMEN
Como consecuencia de una mayor disposicin de las organizaciones en desplegar sus procesos de negocio en sistemas colaborativos, las aplicaciones han evolucionado hacia servicios online de alta complejidad donde los recursos suelen estar distribuidos en diferentes plataformas y tecnologas. En este nuevo marco, las aplicaciones no solo deben cumplir con los objetivos funcionales por las que fueron creadas, sino adems soportar con especial atencin los aspectos relacionados con la seguridad y el control de acceso a los recursos. Ante esta situacin el modelo RBAC es considerado por las organizaciones como una solucin factible para gestionar el acceso a los recursos, pues da la posibilidad de reflejar de manera sencilla las funciones de los puestos de trabajo a roles en el sistema de informacin. En esta tesis proponemos un enfoque para asistir a los desarrolladores en las tareas de integrar los aspectos de seguridad y control de acceso a sus propios diseos durante las etapas tempranas de un proyecto de software. Particularmente nos centramos en presentar un framework arquitectnico que asocia las fortalezas del modelo RBAC y las Arquitecturas Orientadas a Servicios. El diseo arquitectural obtenido apunta esencialmente a disminuir los costos de un proyecto de software y alivianar las tareas de gestin del control de acceso a los ingenieros y diseadores de software.
VII
SUMMARY
As a result of a greater willingness of the organizations to unfold their processes of businesses in collaborative systems, the applications have evolved towards online services of high complexity where the resources are usually distributed in different platforms and technologies. In this new framework, the applications not only must fulfill the functional objectives for which they were created, but also support with special attention the aspects related to security and access control to the resources. In view of this situation, the RBAC model is considered for the organizations as a feasible solution to manage the access to the resources, since it gives the possibility of reflecting in a simple way the functions of the jobs into roles in the information system. In this thesis we propose an approach to assist to the developers in the task of integrating the aspects of security and access control to its own designs during the early stages of a software project. Particularly we concentrated in presenting an architectural framework that combines the strengths of the RBAC model and the Service Oriented Architectures. The obtained architectural design essentially aims to diminish the costs of a software project and to lighten the management tasks of the access control to the engineers and software designers.
ndice general
Captulo 1 .................................................................................................................... 1 Introduccin al Proyecto ........................................................................................... 1 1.1 Motivacin ........................................................................................................ 1 1.2 Objetivo ............................................................................................................ 3 1.3 Organizacin ..................................................................................................... 3 Captulo 2 .................................................................................................................... 5 Tecnologia Subyacente ............................................................................................. 5 2.1 Que es SOA? ................................................................................................... 5 2.2 XML (Extensible Markup Language) ................................................................ 6 2.3 Qu son los Servicios Web? ............................................................................. 6 2.3.1 XML y Los Servicios Web ............................................................................. 7 2.4 SOAP (Protocolo Simple de Acceso a Objetos) ................................................. 8 2.5 WSDL (Lenguaje de Descripcin de Servicios Web .......................................... 9 2.6 UDDI (Universal Description Discovery and Integration)................................ 10 2.7 Infraestructura para laboratorios de acceso remoto........................................... 11 Captulo 3 .................................................................................................................. 12 RBAC (Control de Acceso Basado en Roles) .......................................................... 12 3.1 Caractersticas del Modelo RBAC................................................................... 12 3.2 Fundamentos del control del acceso................................................................. 13 3.3 Simplificacin del control del acceso con roles ................................................ 14 3.4 Modelos RBAC y su evolucin ....................................................................... 14 3.4.1 RBAC0 ......................................................................................................... 14 3.4.2 RBAC1 ......................................................................................................... 15 3.4.3 RBAC2 ......................................................................................................... 16 3.4.4 RBAC3 ......................................................................................................... 17 3.5 Reglas del Sistema RBAC ............................................................................... 17 3.6 Limitaciones del modelo ................................................................................. 20 3.7 Conclusiones sobre el modelo RBAC .............................................................. 20 Captulo 4 .................................................................................................................. 22 Presentacin de la Arquitectura Propuesta ............................................................... 22 4.1 Porqu elegimos una Arquitectura Orientada a Servicios para el diseo de nuestro Framework? .............................................................................................. 22 4.2 Arquitectura RBAC Orientada a Servicios ....................................................... 23 4.2.1 Descripcin de las capas de la Arquitectura .................................................. 24 4.2.2 Distribucin de los componentes de la Arquitectura RBAC .......................... 25 4.2.3 Interaccin entre los componentes de la Arquitectura RBAC ........................ 27 4.2.4 Ejemplo prctico de cmo integrar nuestra Arquitectura RBAC Orientada a Servicios a un desarrollo en Netbeans 6.1 .............................................................. 30 Captulo 5 .................................................................................................................. 34 Mdulo de Configuracin RBAC ............................................................................ 34
9 5.1 Configuracin RBAC ...................................................................................... 34 5.1.1 Planificacin de la distribucin de RBAC ..................................................... 34 5.1.1.1 Planificacin de los roles ........................................................................... 34 5.1.1.2 Planificacin de las autorizaciones para los roles ....................................... 35 5.2 Base de Datos RBAC ...................................................................................... 35 5.3 Empleando el Modulo de Configuracin RBAC ............................................. 37 5.3.1 Configuracin de Roles, Usuarios y Autorizaciones...................................... 37 5.3.2 Configuracin de los Roles ........................................................................... 37 5.3.2.1 Agregar un Rol .......................................................................................... 37 5.3.2.2 Eliminar un Rol ......................................................................................... 38 5.3.2.3 Jerarqua de Roles...................................................................................... 38 5.3.2.4 Separacin esttica y dinmica de responsabilidades y tareas ..................... 39 5.3.3 Configuracin de los Usuarios ...................................................................... 41 5.3.3.1 Asignacin de los roles a usuarios ............................................................. 41 5.3.4 Configuracin de las autorizaciones.............................................................. 42 Captulo 6 .................................................................................................................. 43 Conclusiones y Trabajos Futuros ............................................................................. 43 6.1 Resultados obtenidos del diseo de nuestra Arquitectura ................................. 43 6.2 Trabajos Futuros.............................................................................................. 44 Anexo A ..................................................................................................................... 46 Implementacin de la Arquitectura Propuesta.......................................................... 46 A.1 Implementacin del componente Ejecutor ...................................................... 46 A.2 Implementacin del componente Conmutador ................................................ 49 A.3 Implementacin del componente RBAC ......................................................... 53
ndice de figuras
2.1: Los servicios Web en Funcionamiento. 2.2: Composicin del mensaje SOAP. 2.3: Estructura de un documento WSDL. 3.1: Modelos RBAC. 3.2: Modelo RBAC0. 3.3: Modelo RBAC1. 3.4: Modelo RBAC2. 3.5: Modelo RBAC3. 4.1: Arquitectura RBAC Orientada a Servicios. 4.2: Diagrama de Componentes y distribucin. 4.3: Diagrama de secuencias de interaccin entre componentes 4.4: Diagrama de secuencias de interaccin entre componentes (segundo escenario) 4.5: Crear un Web Service Client en Netbeans 6.1 4.6: Web Service Clients creados en el proyecto Laboratorio 4.7: Operaciones del Servicio Web RBAC 5.1: Diagrama Entidad Relacin para el modelado de base de datos RBAC 5.2: Formulario de Alta de Roles 5.3: Formulario para Eliminar un Rol 5.4: Formulario para Configurar la Jerarqua de Roles 5.5: Formulario para Configurar la Separacin Dinmica entre Roles 5.6: Formulario para Configurar la Separacin Esttica entre. 5.7: Formularios de Alta y Baja de Usuarios. 5.8: Formulario para Configurar la relacin Usuario Rol. 5.9: Formulario para Configurar las Autorizaciones. A.1: Parmetros de la operacin puedeEjecutar del servicio Web Ejecutor A.2: Parmetros de la operacin verificarAcceso del servicio Web Conmutador A.3: Parmetros de la operacin iniciarSesionRBAC del servicio Web RBAC A.4: Parmetros de la operacin finalizarSesion del servicio Web RBAC. A.5: Parmetros de la operacin buscarRolesJerarquia del servicio Web RBAC A.6: Parmetros de la operacin verificarAutorizacin del servicio Web RBAC A.7 Parmetros de la operacin verificarAutorizacin del servicio Web RBAC
Captulo 1
Introduccin al Proyecto
En este Captulo presentamos el contexto sobre el que se desarroll nuestro trabajo. El detalle del contexto se instrumenta explicando la motivacin que dio origen a este proyecto de tesis, incluyendo conceptos y definiciones preliminares relacionados a los objetivos de esta tesis.
1.1 Motivacin
Hoy en da los sistemas empresariales tienden a implementar procesos colaborativos, en los que diferentes usuarios o subsistemas cooperan entre si para realizar actividades relacionadas al negocio. Esto provoca relaciones y dependencias complejas entre las actividades y los usuarios que las realizan, por lo que para garantizar la seguridad de la informacin, se hace necesaria una administracin que maneje diferentes niveles de acceso a las funciones o tareas, como as tambin a los recursos que estas implican. Dada la tendencia de que las tecnologas heterogneas y plataformas diferentes continuarn coexistiendo, las organizaciones optan por implementar sus procesos de negocios anticipndose a este nuevo cambio. La Web ha sido sin duda el medio ms elegido para llevar a cabo este desafo, ayudando notablemente a mejorar la eficiencia y flexibilidad en las aplicaciones, generando asimismo la necesidad de poner ms atencin a los aspectos relacionados con la seguridad y el control de acceso. En este nuevo marco tecnolgico las tareas de administracin y control de los usuarios, las funciones o actividades y los permisos de acceso a los recursos se tornan considerablemente ms complejas, por lo que los desarrolladores tendrn que invertir mayor esfuerzo no solo en lograr los objetivos del negocio, sino tambin en estos aspectos relacionados con la seguridad. Las arquitecturas orientadas a servicio proveen una clara solucin para permitir que los sistemas expongan su funcionalidad por medio de interfaces operables estandarizadas, logran la modularidad apropiada y disminuyen el acople entre los mdulos con mayor interoperabilidad [12]. En este contexto, donde los servicios estn distribuidos, los usuarios finales tendrn que controlar su interaccin obteniendo la informacin que desean en documentos XML generados dinmicamente. Diferentes usuarios pueden tener diferentes intereses e incluso diferentes niveles de accesos a esa informacin, y los servidores debern conocer con precisin qu datos concretos pueden leer y/o modificar y cules no. Por este motivo la arquitectura tendr que soportar un control de acceso para cada usuario en cuestin, lo cual implica que en ocasiones se permitir o se denegar el acceso a los recursos. Las polticas de control de acceso a recursos y funciones actualmente tienen mucho dinamismo en las compaas, y es necesario ser capaz de definir un modelo de control de acceso lo suficientemente flexible como para adaptarse a los cambios. El control de
Captulo 1-Introduccin al Proyecto
acceso es un elemento clave en la seguridad de un sistema y sirve como complemento importante a la definicin de la interaccin entre los usuarios del sistema y, en el caso de sistemas distribuidos, a la interaccin y coordinacin entre los diferentes usuarios y los recursos que utilizan. Uno de los modelos mas usados en la actualidad de control de acceso es el basado en roles, comnmente denominado RBAC (Role-Based Access Control) [8]. Este modelo emerge rpidamente en 1990 como tecnologa para asegurar y mantener la seguridad en sistemas a gran escala en grandes compaas. Es una tecnologa que est atrayendo gran atencin por su potencial para reducir la complejidad y el costo en la administracin de la seguridad en grandes aplicaciones distribuidas. Este modelo permite expresar de forma sencilla y natural la poltica de accesos a los recursos de la organizacin, y adems se caracteriza por la nocin de que los permisos son asignados a roles, y no directamente a los usuarios, quienes son asociados luego a sus correspondientes roles de acuerdo a su funcin en el sistema, relacionando de esta manera implcitamente los permisos a los usuarios. El modelo RBAC incluye un conjunto de sesiones donde cada sesin es la relacin entre un usuario y un subconjunto de roles que son activados en el momento de establecer dicha sesin. Cada sesin est asociada con un nico usuario y cada usuario tiene una o ms sesiones. Los permisos disponibles para un usuario son el conjunto de permisos asignados a los roles que estn activados en todas las sesiones del usuario, sin tener en cuenta las sesiones establecidas por otros usuarios en el sistema [4]. RBAC aade la posibilidad de modelar una jerarqua de roles de forma que se puedan realizar generalizaciones y especializaciones en los controles de acceso, y de esta manera lograr integrar los aspectos de seguridad con los funcionales de una organizacin. Consideramos tambin que durante el desarrollo de un sistema los costos relacionados a los cambios en los requisitos o a la aparicin de nuevos requerimientos son una parte considerable del costo total del desarrollo. En nuestra opinin, es importante poder llevar a cabo una integracin de los elementos de seguridad con el resto de los requerimientos o funcionalidades del sistema en etapas tempranas del proyecto, pero sin interferir demasiado. Hacemos nfasis en esto porque los elementos relacionados con la seguridad se dejan en muchos casos para etapas finales del proceso de desarrollo provocando fuertes incrementos en el costo del producto final. Los temas de seguridad son tan importantes y complejos como para necesitar ser abordados desde las primeras etapas del proyecto y con modelos que faciliten su adaptacin y dinamismo. Por esta situacin nos enmarcamos en la tarea de proponer una arquitectura especfica que sirva a los desarrolladores adaptar fcilmente el control de acceso al diseo de una aplicacin distribuida. Particularmente para nuestro caso de estudio utilizamos la aplicacin Laboratorio Remoto. Es un proyecto de investigacin de software para procesos colaborativos iniciado en el Departamento de Ciencias de la computacin, Universidad Nacional del Comahue [5].
1.2 Objetivo
1.2 Objetivo
En este trabajo vamos a presentar una arquitectura RBAC basada en servicios Web, que sirva de framework a los diseadores y desarrolladores de software para que puedan integrar fcilmente el control de acceso a sus diseos y modelos empresariales, lograr disminuir el tiempo y costo respecto al control de acceso y permitir de esta manera que los analistas inviertan ms esfuerzo en los procesos de negocio de la organizacin. Para alcanzar este objetivo tuvimos en cuenta los siguientes enfoques de una Arquitectura SOA: - Desde un punto de vista arquitectnico separamos los aspectos de seguridad de los propios de la aplicacin, con el objetivo de tener un mayor control de la ejecucin de estos ltimos. Las arquitecturas orientadas a servicios Web son una buena plataforma para realizar esta separacin, porque al estar basadas en estndares favorece a la modularizacin e integracin [12]. - Desde el punto de vista de la definicin de los procesos de negocio separamos los aspectos relacionados con el manejo del flujo de trabajo en la organizacin con aquellos que especifican el contexto de ejecucin de cada uno de esos procesos, consiguiendo una mayor flexibilidad en la administracin y gestin de procesos. - A nivel arquitectnico incluimos un subsistema por cada conjunto de aspectos funcionales. Como, en muchos casos, esos subsistemas tienen que interactuar con los otros, una solucin es la implementacin de cada uno de ellos como un servicio Web. Esto hace que cada parte del sistema pueda usar las dems en forma absolutamente transparente.
1.3 Organizacin
Este trabajo de tesis se organiza de la siguiente manera: 1. En el captulo 2 se describe brevemente la tecnologa subyacente en la cual est fundada esta tesis, y as familiarizar al lector con los tpicos necesarios que le permitirn comprender el desarrollo de los dems captulos. 2. En el capitulo 3 se introduce al Modelo de Control de Acceso Basado en Roles (RBAC, Role-Based Access Control). Primero se describen las principales caractersticas y ventajas del modelo. Luego se presentan las reglas que el modelo debe contemplar para una correcta implementacin. Y por ultimo se nombran algunas limitaciones que dan pie a futuras mejoras. 3. En el capitulo 4 se describe la Arquitectura Propuesta y cada uno de los componentes. Luego se muestra un ejemplo prctico de cmo integrar nuestra Arquitectura RBAC Orientada a Servicios a un desarrollo en Netbeans 6.1 [10] 4. En el captulo 5 se presenta el desarrollo de un modulo de Configuracin RBAC en lenguaje Java [11], que sirve para gestionar una distribucin RBAC en una organizacin.
Captulo 1-Introduccin al Proyecto
5. En el Capitulo 6 se presentan las conclusiones de los resultados obtenidos y los posibles trabajos futuros destacando los aportes y limitaciones de esta tesis. 6. En el Anexo I se muestra el desarrollo de un Prototipo del modelo RBAC orientado a servicios web en lenguaje java.
Captulo 2
Tecnologa Subyacente
En el siguiente captulo vamos a hacer una breve revisin de la tecnologa subyacente, para familiarizar al lector con los tpicos necesarios que le permitirn comprender mejor los objetivos planteados. Si bien los tems descriptos en este capitulo no llegan a desplegar en detalle todo el contenido de cada una de las tecnologas, si ayuda al lector a tener una visin suficiente como para comprender las partes de la tesis, y lograr una lectura fluida del material aqu presentado. El objetivo de este captulo es que se entienda el concepto de cada una de las siguientes tecnologas: SOA XML SOAP Servicios Web WSDL UDDI
2.1 Que es SOA?

El concepto de servicio no es nada nuevo, pero la nocin de Arquitectura Orientada a Servicios (SOA, Software Oriented Architecture) [12] ha evolucionado a travs de los ltimos aos. Este avance ha dado lugar a un estilo de arquitectura de software que tiene como caracterstica principal promover el desacople entre los componentes de forma que se puedan reutilizar, y as permitir crear aplicaciones basada en servicios independientes de la plataforma, lenguaje y sistema operativo. El elemento bsico de SOA es el servicio [12], el cual es un mdulo de software auto contenido que realiza una determinada tarea. Los servicios son componentes de software que no requieren que los desarrolladores usen una tecnologa subyacente especfica sino que promueve el ensamblaje de aplicaciones, pues estos pueden ser reutilizados por varios consumidores. Una caracterstica interesante de este tipo de arquitectura es que nos permite automatizar la administracin de procesos de negocio, y as luego orquestar los servicios para lograr la funcionalidad deseada, y por consiguiente dar lugar a que nuevos procesos de negocio se puedan construir utilizando los servicios existentes. Por ejemplo, el pedido de un cliente puede estar representado por un proceso de negocio que interacte asincrnicamente con los servicios necesarios. En resumen, podramos listar las siguientes ventajas [12] de las Arquitecturas SOA:
Captulo 2-Tecnologa Subyacente
Nos permite fcilmente adaptar las aplicaciones a las tecnologas cambiantes. Nos da la posibilidad de integrar simplemente las aplicaciones con otros sistemas. Nos deja aprovechar las inversiones hechas en sistemas heredados. Nos da la opcin de reutilizar servicios hechos con anterioridad e integrarlos a un proyecto de software actual.
2.2 XML (Extensible Markup Language)

Es un metalenguaje que especifica la sintaxis utilizada para definir otros lenguajes de etiquetas estructurados. Es una arquitectura ms abierta y extensible, pues no necesita versiones para que puedan funcionar en distintas versiones de navegadores, adems los identificadores pueden crearse de manera simple y ser adaptados en el acto en Internet/intranet por medio de un validador de documentos (parser) [13]. Con XML se obtiene mayor consistencia, homogeneidad y amplitud de los identificadores descriptivos de documentos (los RDF Resource Description FrameWork), con el objetivo de integrar datos e intercambiar documentos entre las aplicaciones tanto en la propia PC como en una red local o extensa. La extensibilidad y flexibilidad de este lenguaje nos permite agrupar una variedad amplia de aplicaciones, desde pginas Web hasta bases de datos. Otra ventaja es que los documentos XML son fciles de leer y razonablemente claros, esta caracterstica hace que sea muy simple escribir programas para procesar este tipo de documentos.
2.3 Qu son los Servicios Web?

Son componentes de software cuya caracterstica principal es proporcionar mecanismos de comunicacin estndares entre diferentes aplicaciones, que interactan entre s para presentar informacin dinmica al usuario. Se los puede definir como el medio para exponer y hacer disponible la funcionalidad de los sistemas de informacin mediante las tecnologas estndar Web, la cual reduce el efecto de la heterogeneidad de las diferentes plataformas que tienden a coexistir en los sistemas de hoy en da [5]. Definicin del World Wide Web Consortium (W3C) [14]: Una aplicacin software identificada por un URI (Uniform Resource Identifier), cuyas interfaces se pueden definir, describir y descubrir mediante documentos XML. Un servicio Web soporta interacciones directas con otros agentes software utilizando mensajes XML intercambiados mediante protocolos basados en Internet. Para proporcionar interoperabilidad y extensibilidad entre estas aplicaciones, y que al mismo tiempo sea posible su combinacin para realizar operaciones complejas, es necesaria una arquitectura de referencia estndar.
2.3 Qu son los Servicios Web?
La figura 2.1 muestra cmo interacta un conjunto de Servicios Web:
Figura 2.1 - Los servicios Web en Funcionamiento
Segn el ejemplo de la figura 1, podemos describir la siguiente situacin. Un usuario, que posee el papel de cliente dentro del esquema de Servicios Web, solicita informacin a travs de una aplicacin cliente haciendo una peticin al servicio Web A, que ofrece sus servicios a travs de Internet. Para proporcionar al cliente la informacin que necesita, este servicio solicita a su vez informacin a otros recursos (otros Servicios) lo que lo convierte a su vez en cliente de otros Servicios Web que le van entregando la informacin requerida. En todo este proceso intervienen una serie de tecnologas que hacen posible esta circulacin de informacin, que describiremos en las siguientes secciones de este captulo. 2.3.1 XML y Los Servicios Web Ahora que ya conocemos algo ms sobre XML nos queda responder porque XML es utilizado en los servicios Web? Ya se han mencionado algunas pistas para esta pregunta, pero para hacerlo ms prctico diremos que se utiliza XML por las siguientes razones [2]:
Es un estndar abierto, pues es reconocido mundialmente por muchas compaas tecnolgicas que integran en su software compatibilidad con dicho lenguaje. Esto quiere decir que la gran mayora del software permite la compatibilidad con XML por lo que lo hace muy potente a la hora de facilitar la comunicacin entre distintas plataformas de software y hardware (si recordamos bien este es el sentido final de los Servicios Web). Posee gran simplicidad de sintaxis, esto quiere decir que es muy fcil de escribir cdigo en XML y la representacin de los datos es casi entendible por cualquier ser humano. Esto lo hace muy flexible a la hora de querer representar datos de cualquier especie. Basta con disponer de cualquier editor de texto y aprender unas cuantas instrucciones bsicas para estar en condiciones de escribir cdigo XML, el cual ser soportado o entendido por cualquier aplicacin. El hecho de
que este metalenguaje sea tan fcil de codificar y de entender lo convierte en el lenguaje ideal para utilizarlo en los servicios Web.
No necesita de ningn protocolo de trasporte especial, solo de un protocolo que pueda transferir texto o documentos simples.
2.4 SOAP (Protocolo Simple de Acceso a Objetos):

Se trata de un protocolo basado en XML, que permite la interaccin entre varios dispositivos; se destaca por su capacidad de transmitir informacin compleja. Los datos pueden ser transmitidos a travs de HTTP, SMTP, o algn otro protocolo de transporte a travs de un formato especifico de mensajes. Por lo tanto el objetivo de SOAP es organizar la informacin utilizando XML de forma estructurada y tipada de forma tal que pueda ser intercambiada entre iguales [13]. El mensaje SOAP, como muestra la figura 2.2, est compuesto por un envelope (sobre), cuya estructura est formada por los siguientes elementos: header (cabecera) y body (cuerpo).
Figura 2.2 Composicin del mensaje SOAP
En resumen podemos decir que el protocolo SOAP posee las siguientes caractersticas: Un formato de mensaje para comunicaciones en una direccin, describiendo como se organiza la informacin en un documento XML. Un conjunto de normas para implementar interacciones al estilo RPC mediante mensajes SOAP, definiendo como los clientes pueden invocar un procedimiento remoto enviando un mensaje SOAP y como los servicios pueden replicar enviando otro mensaje al cliente.
2.4 SOAP (Protocolo Simple de Acceso a Objetos)
Un conjunto de reglas que cualquier entidad que procesa un mensaje SOAP debe seguir, las cuales definen que elementos deberan leer y comprender, y las acciones que deberan realizar en caso que el contenido sea incomprensible. Una descripcin de cmo su mensaje SOAP se debera transportar sobre HTTP y SMTP.
2.5 WSDL (Lenguaje de Descripcin de Servicios Web)

El lenguaje de descripcin de servicios Web (WSDL, Web Service Description Language) [13] es un dialecto basado en XML para describir un servicio Web que proporciona la informacin necesaria al cliente para interactuar con el servicio. Es extensible y se pude utilizar para detallar, prcticamente, cualquier servicio de red, incluyendo SOAP sobre HTTP e incluso protocolos que no se basan en XML como DCOM sobre UDP. Dado que los protocolos de comunicaciones y los formatos de mensajes estn estandarizados en la comunidad del Web, cada da aumenta ms la posibilidad e importancia de describir las comunicaciones de forma estructurada. WSDL afronta esta necesidad definiendo una gramtica XML que describe los servicios de red como colecciones de puntos finales de comunicacin capaces de intercambiar mensajes. Las definiciones de servicio de WSDL proporcionan documentacin para sistemas distribuidos y sirven como frmula para automatizar los detalles que toman parte en la comunicacin entre aplicaciones. En WSDL, la definicin abstracta de puntos finales y de mensajes se separa de la instalacin concreta de red o de los enlaces del formato de datos [1]. Esto permite la reutilizacin de definiciones abstractas: mensajes, que son descripciones abstractas de los datos que se estn intercambiando y tipos de puertos, que son colecciones abstractas de operaciones. Las especificaciones concretas del protocolo y del formato de datos para un tipo de puerto determinado constituyen un enlace reutilizable. Un puerto se define por la asociacin de una direccin de red y un enlace reutilizable; una coleccin de puertos define un servicio. Por esta razn, un documento WSDL utiliza los siguientes elementos en la definicin de servicios de red:

Types: contenedor de definiciones del tipo de datos que utiliza algn sistema de tipos (por ejemplo XSD). Message: definicin abstracta y escrita de los datos que se estn comunicando. Operation: descripcin abstracta de una accin admitida por el servicio. Port Type: conjunto abstracto de operaciones admitidas por uno o ms puntos finales. Binding: especificacin del protocolo y del formato de datos para un tipo de puerto determinado. Port: punto final nico que se define como la combinacin de un enlace y una direccin de red. Service: coleccin de puntos finales relacionados.
En la figura 2.3 se puede observar cmo se distribuyen estos elementos en el bloque Abstracto o Concreto respectivamente de la estructura de un documento WSDL:
10
Figura 2.3 Estructura de un documento WSDL
2.6 UDDI (Universal Description Discovery and Integration)

Una vez definido y creado un servicio Web, el siguiente paso consiste en definir cmo se dar a conocer el servicio Web para que los clientes interesados puedan descubrirlo fcilmente y utilizarlo en sus aplicaciones. En la actualidad, ya existe un mecanismo de descubrimiento que cumple estos requisitos: UDDI (Universal Description Discovery and Integration) [13], el cual es un registro pblico diseado para almacenar de forma estructurada informacin sobre empresas y los servicios que stas ofrecen. A travs de UDDI, se puede publicar y descubrir informacin de una empresa y de sus servicios. Se puede utilizar sistemas taxonmicos estndar para clasificar estos datos y poder encontrarlos posteriormente en funcin de la categorizacin. Lo ms importante es que UDDI contiene informacin sobre las interfaces tcnicas de los servicios de una empresa. A travs de un conjunto de llamadas a API XML basadas en SOAP, se puede interactuar con UDDI tanto en tiempo de diseo como de ejecucin para descubrir datos tcnicos de los servicios que permitan invocarlos y utilizarlos.
2.7 Infraestructura para laboratorios de acceso remoto
11
2.7 Infraestructura para laboratorios de acceso remoto

A continuacin mostramos una breve resea sobre lo que es este proyecto del Departamento para Ciencias de la Computacin de la Universidad Nacional del Comahue. Nuestra tesis basar su experimentacin en aplicar la arquitectura RBAC propuesta a sistemas de procesos colaborativos como lo es este proyecto, especficamente en el captulo 4 seccin 4.2.3 detallamos un caso de estudio que consiste en cmo aplicar el framework propuesto para lograr control de acceso basado en roles al Laboratorio Remoto. Un laboratorio de acceso remoto (LAR) es "un espacio de trabajo electrnico para la colaboracin y experimentacin en investigacin u otras actividades creativas, para la generacin y distribucin de los resultados de investigacin utilizando tecnologas de informacin distribuidas" [3]. Este trabajo describe una infraestructura para la implementacin de aplicaciones para el acceso remoto a laboratorios y para la gestin de los mismos. La meta de este proyecto apunta a complementar las tareas de aprendizaje con un soporte tecnolgico de sistemas, entendido como todas aquellas actividades de infraestructura que promuevan la disponibilidad de recursos y apoyan la escalabilidad de procesos en la tarea educativa sostenida por tecnologas de informacin. Plantea aprovechar el avance en las tecnologas de internet y el aumento de la velocidad de los medios de comunicacin digitales con el fin de desarrollar software distribuido, y as lograr alta disponibilidad de recursos virtuales y fsicos a mayor cantidad de investigadores y estudiantes, apuntando a lograr de esta manera buenas prcticas de enseanza y aprendizaje. Los analistas e implementadores de laboratorios de acceso remoto deben disear y desarrollar arquitecturas de servicios que permitan un acceso flexible y controlado. De esta manera se logra un nivel de independencia entre la informacin que generan o consumen los recursos y el medio utilizado para ello, que permite agregar nuevos recursos a los LAR sin modificar sus arquitecturas de servicios actuales, sino extendiendo y adaptndose a las mejores tecnologas de comunicacin. Para llevar a cabo la construccin de este trabajo, se dise un Framework Orientado a Objetos (FOO) basado en Java que permite la implementacin de aplicaciones altamente adaptables a los cambios tecnolgicos y desacopladas de las tecnologas de comunicacin utilizadas para el acceso, obteniendo herramientas reusables para el acceso a distintos laboratorios, sin importar las tecnologas por las cuales se acceda, adems de facilitar la adicin y el acceso a nuevos servicios. Para la implementacin de los servidores de laboratorios los desarrolladores se basaron en una arquitectura favorable a los accesos concurrentes y colaborativos de distintos usuarios a los recursos fsicos y virtuales provistos por una o ms organizaciones. En base al marco tecnolgico que ofrece este proyecto informtico, planteamos en esta tesis el diseo de un framework que logre adaptarse fcilmente a sistemas distribuidos colaborativos sin interferir demasiado en el desarrollo y construccin de los mismos.
Captulo 3
RBAC (Control de Acceso Basado en Roles)
El Control de Acceso Basado en Roles (RBAC, Role Based Access Control) [8], es una tecnologa que lleg para satisfacer necesidades de control de acceso a grandes sistemas empresariales. Fue ganando terreno en lo que se refiere a modelos de control de acceso, por su flexibilidad para adaptarse a las polticas de una organizacin con un bajo costo de mantenimiento. En un principio la administracin de los perfiles de acceso a estos sistemas se llevaba a cabo mediante Listas de Control de Acceso (ACLs) [4], pero a medida que el padrn de usuarios creca, se haca ms complejo y costoso el mantenimiento de estas. Sin embargo, actualmente este tipo de problemas ha disminuido gracias a que la seguridad est siendo llevada con RBAC. Este modelo consiste en que los roles deben asignarse adecuadamente a las diferentes tipos de personas, segn sus capacidades y funciones que desempean cada una de ellas. Este Captulo se organiza de la siguiente manera: de la seccin 3.1 a la 3.3 se resume el alcance y caractersticas del modelo. En la seccin 3.4 se describe la evolucin del modelo durante el tiempo; en la seccin 3.5 presentamos las reglas que describen el marco del modelo en base a sus posibilidades y restricciones. Por ltimo, para finalizar con el capitulo, se dan a conocer algunas limitaciones del modelo y una conclusin final.
3.1 Caractersticas del Modelo RBAC

La principal caracterstica de RBAC es que ofrece la posibilidad de ajustar la especificacin de las polticas de seguridad acorde a la estructura de una organizacin. Esta aproximacin de la seguridad a la estructura empresarial permite crear de manera natural los roles segn las caractersticas y funciones ya preestablecidas en la organizacin. El modelo usa el concepto de rol en vez de la asignacin de privilegios directamente a usuarios, lo cual implica que a cada usuario se le asignan uno o ms roles, y a cada rol se le asignan los privilegios que se les permiten a los usuarios que actan en ese rol. Esto facilita la clasificacin de privilegios y permite un control de acceso fino a los recursos [7]. Anteriormente el control de acceso en los sistemas empresariales se basaba en proporcionar a los administradores la contrasea de una cuenta comn compartida. Aunque esta cuenta simplificaba el control de accesos al permitir que los administradores que disponan de la contrasea de usuario administrador pudieran realizar todas las operaciones, tambin presentaba varios obstculos inherentes para la gestin de acceso a los recursos. Por ejemplo:
3.1 Caractersticas del Modelo RBAC

13
Despus de proporcionar a los administradores la contrasea de usuario administrador, no resultaba fcil limitar en mayor medida a estos usuarios. En el mejor de los casos, revocar el acceso de un administrador requera la modificacin de la contrasea comn y la notificacin a los dems administradores. Pero siendo ms realistas, la sola modificacin de la contrasea no resultaba ser suficiente para revocar de forma efectiva el acceso, ya que se podran haber puesto en marcha otros mecanismos de acceso alternativos. La responsabilidad individual era prcticamente imposible de ejercer con una cuenta de usuario administrador compartida. En consecuencia, resultaba difcil realizar un anlisis adecuado despus de producirse un suceso de seguridad y, en algunos casos, imposible.
Con el modelo RBAC se logr eliminar estos obstculos al ofrecer la capacidad de asignar conjuntos de tareas a cuentas de usuario ordinarias configuradas apropiadamente, y tambin conseguir mitigar la sobrecarga de administracin asociada a asignar y revocar las autorizaciones individuales para cada usuario. En resumen, el modelo RBAC [6] ofrece las siguientes caractersticas: Una base de datos de configuracin predefinida, para una distribucin rpida y fcil.

La aplicacin de restricciones en funcin de cada recurso. Una arquitectura para personalizar las decisiones relativas al control del acceso.
3.2 Fundamentos del control del acceso

La meta de un sistema de control de acceso es limitar los privilegios a los recursos en funcin de un conjunto de restricciones. El modelo de referencia de RBAC define trminos que componen este modelo como lo son: usuarios, roles, permisos, operaciones y objetos, as como las funciones y relaciones que se incluyen en este estndar [6]. Una solicitud de control de acceso puede considerarse como una pregunta que combina los trminos anteriores, cuya respuesta (normalmente permitir o denegar) determina si se concede el acceso al recurso. Por ejemplo: Est autorizado el usuario Alumno1 para realizar la operacin ingresar en el objeto practico1? A menudo, el trmino autorizacin se emplea como sinnimo de control del acceso. En RBAC, el trmino autorizacin se refiere a la capacidad de realizar una operacin en un objeto. Un usuario puede tener concedidas diversas autorizaciones, cada una de ellas con distintos privilegios sobre los recursos.
14
Captulo 3-RBAC (Control de Acceso Basado en Roles)
3.3 Simplificacin del control del acceso con roles.

Un enfoque simple de control de acceso, como se mencion anteriormente, es mantener una lista con los usuarios y las autorizaciones asignadas a cada uno de ellos. Este enfoque tiene la ventaja de alcanzar cierta flexibilidad, ya que el conjunto de autorizaciones de cada usuario puede ser totalmente distinto de los conjuntos de los dems usuarios [6]. Por desgracia, este enfoque resulta tambin difcil de administrar ya que, a medida que se agregan usuarios, es necesario determinar exactamente qu autorizaciones requiere cada usuario. Asimismo, cuando se realizan auditoras, es necesario examinar cada usuario individualmente para determinar las autorizaciones correspondientes. RBAC resuelve estos problemas agrupando en roles a los usuarios con necesidades de autorizacin comunes. Los roles sirven de mecanismo de agrupacin para simplificar la asignacin y la auditora de las autorizaciones. En lugar de asignar directamente una autorizacin a un usuario, estas se asignan a roles predefinidos. A medida que se agregan usuarios al sistema, se les asigna un conjunto de roles, que determinan las acciones que pueden llevar a cabo y los recursos a los que pueden tener acceso.
3.4 Modelos RBAC y su evolucin

Con el paso del tiempo el concepto de RBAC ha ido evolucionando, dando lugar a la incorporacin de nuevas versiones del modelo, extendiendo su funcionalidad y robustez con cada una de ellas [7]. En esta seccin se describe cada una de las versiones de modelos RBAC conocidas hasta ahora. En la figura 3.1 se muestran en resumen cada uno de los modelos dependiendo si posee jerarqua de roles y/o restricciones.
Figura 3.1 Modelos RBAC
3.4.1 RBAC0 El modelo RBAC0 [7], es el concepto de RBAC, en donde se especifica que un usuario tiene diferentes roles, y cada rol lleva asociado algn permiso. Posee los siguientes componentes centrales del modelo: Conjuntos: USUARIOS (U) ROLES (R) PERMISOS (P) OPERACIONES (OPS) OBJETOS (OBJ)
15
Relaciones Asignacin Permisos: PA P x R (La relacin Asignacin Permisos (PA) est incluida en el producto cartesiano entre los conjuntos Permisos (P) y Roles (R)) Asignacin Usuarios: UA U x R (La relacin Asignacin Usuarios (UA) est incluida en el producto cartesiano entre los conjuntos Usuarios (U) y Roles (R))
Funciones usuario_sesion: S U (A cada sesin del conjunto de Sesiones (S) le corresponde solo un usuario del conjunto de Usuarios (U)) sesion_roles: S 2R (A cada sesin del conjunto de Sesiones (S) le corresponde un subconjunto del conjunto de Roles (R))
Figura 3.2 Modelo RBAC0
En la figura 3.2 podemos observar los conjuntos USUARIOS, ROLES y PERMISOS, y sus respectivas relaciones y funciones, con las siguientes caractersticas: La relacin entre usuarios y permisos (o privilegios) es de muchos a muchos. Una sesin es un funcin entre un usuario y un subconjunto activado de roles. Las relaciones Usuario/Rol pueden ser definidas en forma independiente de las relaciones Rol/Permiso.
3.4.2 RBAC1 Est basado en el modelo RBAC0, e introduce el concepto de jerarqua de roles [7]. Esta propiedad bsicamente consiste en la capacidad que tiene un rol en heredar las autorizaciones de sus roles superiores en la jerarqua. Por lo tanto un rol con mayor jerarqua adquiere los derechos del rol con menor jerarqua, heredando as los privilegios del rol anterior. Por ejemplo, el usuario con mayor jerarqua dentro de una organizacin puede tener acceso a cualquier tipo de informacin, incluso a la informacin que pueda tener el usuario con menor jerarqua, demostrando as que un rol puede ser miembro de otro rol. En la seccin 3.5 se presenta con ms detalle una definicin de este concepto.
16
En la figura 3.3 se puede ver el agregado de la relacin jerarqua de roles al modelo anterior.
Se agrega un orden parcial llamado jerarqua de roles, RH R x R (el conjunto Jerarqua de Roles (RH) est incluido en el producto cartesiano de Roles (R)) Se modifica la definicin de las funciones: sesion_roles (s) {r | Existe r' UA} r. (usuario_sesion(s),r')
(Dada una sesin s aplicada a la funcin sesion_roles, da como resultado un rol r tal que existe un rol r con mayor jerarqua que r, donde el par (r,u), con u como usuario de la sesin s, est incluido en la relacin UA) Un usuario puede establecer una sesin con cualquier combinacin de los roles que sean menores a los que l tiene asignado. Similarmente, los permisos de una sesin son aquellos asignados directamente a los roles de la sesin ms aquellos asignados a los roles que estn dominados por ellos.
3.4.3 RBAC2 Al igual que el modelo anterior, ste tambin est basado en el modelo de RBAC0, pero introduce el concepto de restricciones [7] que veremos con ms detalles en la siguiente seccin. El uso ms frecuente que se tiene con las restricciones es la separacin de tareas dentro de una organizacin. Estas restricciones, conocidas con el nombre de Cardinalidad, Separacin esttica de tareas (SSD) y Separacin Dinmica de Tareas (DSD), sirven para prevenir fraudes restringiendo la combinacin de privilegios
17
disponibles para los usuarios. En la figura 3.4 se muestra el agregado de estas restricciones al modelo RBAC0.
3.4.4 RBAC3 Este es el modelo ms complejo de los que se han presentado con anterioridad, ya que incluye tanto las jerarquas de roles como las restricciones. En RBAC3 [7], las restricciones pueden ser impuestas sobre los roles jerrquicos dentro de una organizacin. La figura 3.5 ilustra la combinacin de RBAC1 y RBAC2 para componer RBAC3
3.5 Reglas del Sistema RBAC

En esta seccin nos enfocamos en representar el marco conceptual de RBAC basndonos en reglas que definen el alcance del modelo y sus restricciones [4]. Estas reglas fueron tenidas en cuentas durante el diseo y desarrollo del Framework propuesto para esta tesis.
18
Regla 1 (Jerarqua de Roles) Si un usuario est autorizado para acceder a un rol y el rol contiene otro rol, entonces el usuario tambin est autorizado para acceder al rol contenido [4]. En RBAC, los roles asociados a un usuario pueden tener operaciones en comn, lo que hace que especificar la funcionalidad de cada rol por separado se haga complejo y difcil de administrar. Para simplificar esta situacin, el modelo ofrece la posibilidad de definir el conjunto de roles en la organizacin, de manera tal que se pueda identificar aquellas operaciones superpuestas entre cada uno de ellos, y tambin aquellas operaciones que son nicas para cada rol. Esta tarea aade la posibilidad de modelar una jerarqua de roles de forma que se puedan realizar generalizaciones y especializaciones en los controles de acceso y facilitar la modelizacin de la seguridad en sistemas ms complejos. El sistema RBAC diseado para esta tesis permite administrar y configurar los roles de tal forma que se pueda especificar claramente la jerarqua de roles de manera natural y cumplir sin problemas con esta regla. Regla 2 (Separacin Esttica de Tareas) Un usuario estar autorizado como miembro de un rol solo si ese rol no es mutuamente exclusivo con cualquiera de los otros roles de los cuales el usuario ya es miembro [4]. Dos roles son mutuamente exclusivos cuando un mismo usuario no puede ser miembro de ambos roles, pues las operaciones de dichos roles generan conflicto de intereses. Para asegurar esta propiedad el sistema RBAC debe proveer de una herramienta para llevar a cabo una poltica de Separacin Esttica de Tareas, y as validar que al momento de asignar un rol a un usuario cumpla con esta regla. Regla 3 (Cardinalidad) La capacidad de un rol no puede ser excedida por un miembro adicional [4]. Se debe permitir especificar la capacidad de un Rol, y asegurar que sta no sea sobrepasada en la asignacin de usuarios a dicho rol. Un usuario puede convertirse en un nuevo miembro de un rol siempre y cuando el nmero de miembros permitidos para el rol no sea excedido. Con esta restriccin se pueden controlar aun ms los miembros de un rol. Por ejemplo, se pueden limitar las asignaciones al rol administrador, asegurando que no haya ms de una cantidad mnima de usuarios administradores en el sistema. Regla 4 (Autorizacin de Roles) Un usuario nunca podr tener un rol activo que no est autorizado para ese usuario [4]. El sistema RBAC debe verificar que un rol sea parte del conjunto de roles autorizados para un usuario antes de proceder a activarlo en la correspondiente sesin, y as luego permitir ejecutar alguna operacin de dicho rol.
3.5 Reglas del Sistema RBAC
19
Regla 5 (Ejecucin de Roles) Un usuario puede ejecutar una operacin, solo si el usuario est actuando dentro de un rol activo. A medida que el usuario solicita acceso a distintos recursos del sistema, RBAC va activando sobre la sesin aquellos roles que poseen la autorizacin correspondiente para realizar la tarea requerida. Para llevar a cabo la activacin de un rol en tiempo de ejecucin se debe verificar lo siguiente: Que el usuario sea miembro del rol en cuestin. Que este no sea mutuamente exclusivo con otro rol activo en la misma sesin (Separacin Dinmica de Tareas) Y como ltimo punto, que la operacin propuesta sea consistente con las polticas y restricciones preestablecidas en la organizacin.
Regla 6 (Separacin Dinmica de Tareas) Un usuario puede volverse activo en un nuevo rol solo si ese rol no es mutuamente exclusivo con cualquiera de los roles en los cuales est actualmente activo [4]. A diferencia de la Separacin Esttica de Tareas que define restricciones en el momento de vincular un usuario a algn rol, la Separacin Dinmica de Tareas aplica restricciones a las activaciones simultaneas de roles, o sea que se emplea en tiempo de ejecucin. Por ejemplo un usuario puede estar autorizado a ser miembro de dos roles, pero podra asumir dinmicamente solo uno de esos roles a la vez. Regla 7 (Autorizacin de Operaciones) Un usuario puede ejecutar una operacin, solo si est autorizado para el rol en el cual el usuario est actualmente activo [4]. Adems de la regla 5 que se refiere solo a la activacin de roles, esta regla se basa en comprobar que un usuario solo puede ejecutar operaciones que son autorizadas por un rol activo en la sesin. Esto quiere decir que el rol debe pertenecer a la lista de roles activos del usuario o ARS (Active Rol Set). El sistema debe llevar dinmicamente una estructura de datos que implemente el ARS correspondiente a la sesin de un usuario, y dejarla disponible para poder cotejar esta regla. Regla 8 (Separacin Operacional de Tareas) Un rol puede estar asociado con una operacin de una funcin organizacional, solo si el rol es un rol autorizado para el sujeto y el rol no ha sido asignado previamente a ninguna de las otras operaciones [4]. Esta regla, al igual que la separacin esttica y dinmica de tareas, se aplica generalmente para evitar fraudes. Pues se basa en la idea de que si existen varias tareas relacionadas dentro de una mismo rol, se presenta la posibilidad de que un mismo usuario ejecute todas las operaciones de una funcin, por lo general comercial, y tomar pleno control del proceso. Por ejemplo, en la cadena de aprobacin de una orden de compra hasta la recepcin del material puede ser tratada por una sola persona. Si cada una de estas operaciones es ejecutada por diferentes roles, la probabilidad de fraude puede ser disminuida. El sistema debe otorgar facilidades a la hora de configurar
20
los roles y as evitar que un usuario pueda ejecutar una serie de operaciones encadenadas pudiendo llegar a un posible fraude. Regla 9 (Autorizacin de Acceso a Operaciones) Un sujeto puede acceder a un objeto solo si el rol es parte del conjunto de roles actualmente activo del sujeto, el rol est permitido a ejecutar operaciones, y la operacin para acceder al objeto est autorizada [4]. Con las propiedades de Autorizacin de Roles y Ejecucin de Roles definidas anteriormente (Reglas 3 y 4), la propiedad Autorizacin de Acceso a Operaciones definida arriba asegura que el acceso de un sujeto a un objeto RBAC solo puede ser obtenido a travs de operaciones autorizadas para los roles activos autorizados. En definitiva, la Autorizacin de Acceso a Operaciones, indica que el control de los accesos de los sujetos a los objetos RBAC asegura las polticas de la organizacin a los recursos.
3.6 Limitaciones del modelo

El modelo RBAC se caracteriza por las grandes ventajas mencionadas anteriormente, pero sin embargo consideramos que presenta una serie de carencias [8] para el control de acceso en procesos de naturaleza colaborativa, que vale la pena resaltar para futuras mejoras: En RBAC la naturaleza de los roles puede ser denominada esttica, ya que carecen de flexibilidad y sensibilidad para el entorno en el cual son usados. RBAC soporta la nocin de roles activos para un usuario con el concepto sesin, obteniendo a partir de estos roles activos el conjunto de permisos disponibles para un usuario, pero no tiene en consideracin las sesiones establecidas por otros usuarios en el sistema, es decir que el modelo no engloba todo el contexto asociado con el sistema. No es capaz de especificar un control de grano fino sobre usuarios individuales en ciertos roles y sobre instancias de objetos individuales. Un ejemplo a esta situacin podra ser en el laboratorio remoto, donde puede ser necesario crear un grupo de trabajo de estudiantes, con el rol Alumnos de primer ao, que tengan acceso temporal a un recurso en particular. RBAC no puede controlar que otros estudiantes del mismo rol que no pertenecen a dicho grupo de trabajo, accedan o interfieran con el recurso en cuestin. En el escenario descrito anteriormente se observa la necesidad de establecer permisos comunes a grupos de usuario. Esto es conseguido en el modelo RBAC creando un rol especfico y asignando de forma individual este rol a cada usuario
3.7 Conclusiones sobre el modelo RBAC

Consideramos que el modelo RBAC puede ser usado como modelo de partida para la definicin de la arquitectura que se va a presentar en esta tesis. A pesar de las limitaciones anteriormente mencionadas, creemos que posee caractersticas relevantes
3.7 Conclusiones sobre el modelo RBAC
21
que ningn otro modelo de control de acceso posee, y es el que mejor se adapta a sistemas colaborativos, como por ejemplo lo es el proyecto de Laboratorio Remoto de la universidad Nacional del Comahue. El modelo RBAC, adems de adaptar de forma natural las funciones de una organizacin, tiene la habilidad de adecuarse rpida y eficientemente a los cambios estructurales de una organizacin.
Captulo 4
Presentacin de la Arquitectura Propuesta
En este captulo describimos el ncleo de nuestra tesis, una arquitectura RBAC basada en servicios Web, que sirva de Framework a los diseadores y desarrolladores de software, para que puedan integrar fcilmente el control de acceso a sus diseos y modelos empresariales. Explicaremos el comportamiento de cada uno de los componentes de la Arquitectura, sus propiedades observables, y las relaciones existentes entre ellos. Esta comprensin es indispensable para entender cmo aplicar este Framework a un desarrollo propio. Este captulo se organiza de la siguiente manera: en la Seccin 4.1 citamos ventajas por las cuales hemos optado por una arquitectura SOA para implementar nuestro framework de desarrollo; luego en la seccin 4.2 vemos las partes de la Arquitectura y la descripcin de cada uno de sus componentes. Para finalizar con el capitulo se muestra un ejemplo prctico de cmo llevar a cabo la integracin de este Framework a un proyecto de software.
4.1 Porqu elegimos una Arquitectura Orientada a Servicios para el diseo de nuestro Framework?
Las Arquitecturas Orientadas a Servicios (SOA, Service Oriented Architecture) [15] son una filosofa de diseo que permite un mejor alineamiento de las Tecnologas de Informacin (IT) con las necesidades de negocio, logrando un dinamismo en la toma de decisiones, con informacin ms exacta y actualizada. Asimismo con la posibilidad de obtener mejor informacin en un tiempo menor, habilita a las organizaciones a reaccionar de manera ms gil y rpida cuando surgen problemas o cambios. La tecnologa SOA permite una abstraccin en las implementaciones de los servicios promoviendo que los desarrolladores se dediquen de lleno a los procesos importantes del negocio, y as desarrollar aplicaciones de manera ms rpida y econmica. El diseo de servicios basado en estndares facilita la creacin de un repositorio de servicios reutilizables que se pueden combinar en servicios de mayor nivel y aplicaciones compuestas en respuesta a nuevas necesidades de la empresa. Con ello se reduce el costo del desarrollo de soluciones y de los ciclos de prueba, se eliminan redundancias y se consigue su puesta en produccin en menor tiempo. En sntesis, el uso de un entorno y modelo de desarrollo unificado simplifica y homogeneiza la creacin de aplicaciones, desde su diseo y prueba hasta su puesta en marcha y mantenimiento. Finalizando, otra ventaja importante de las soluciones orientadas a servicios es que proporcionan una infraestructura comn (y una documentacin comn tambin) para desarrollar servicios seguros, predecibles y gestionables. Conforme van evolucionando las necesidades de negocio, SOA facilita la posibilidad de aadir nuevos servicios y funcionalidades para gestionar los procesos crticos. Se accede a los servicios y no a las
4.1 Porqu elegimos una Arquitectura Orientada a Servicios para el diseo de nuestro Framework
23
aplicaciones, y gracias a ello se optimizan las inversiones realizadas en IT potenciando la posibilidad de introducir nuevas capacidades y mejoras. Adems, puesto que se utilizan mecanismos de autenticacin y autorizacin robustos en todos los servicios, y puesto que los servicios existen de forma independiente unos de otros y no se interfieren entre ellos, la estrategia de SOA permite dotarse de un nivel de seguridad superior.
4.2 Arquitectura RBAC Orientada a Servicios

En esta Seccin presentamos los elementos que forman parte del diseo de nuestro trabajo, sus relaciones, responsabilidades y colaboraciones. Desde esta perspectiva nuestra Arquitectura est dividida en las siguientes tres capas: Capa de Aplicacin: en esta capa se encuentra la aplicacin cliente que posee los elementos y servicios propios del negocio, e interacta con la capa de Servicios de Control de Acceso para evaluar el acceso a los recursos de la aplicacin, cuando un sujeto as lo requiera. Capa de Servicios de Control de Acceso: Esta capa posee todos los componentes que se encargan de gestionar el control de acceso. Contiene la secuencia de operaciones a llevar a cabo y las polticas de seguridad a tener en cuenta en el momento de otorgar acceso a los recursos de la aplicacin. Interacta con la Capa de Infraestructura RBAC para obtener informacin respecto a Roles, usuarios y autorizaciones. Capa de Infraestructura RBAC: En esta capa se encuentra la base de datos RBAC. En ella se alojan los roles, usuarios y autorizaciones. Esta base de datos posee un mdulo de configuracin donde se personaliza el sistema RBAC acorde a las necesidades de la organizacin cliente.
En la Figura 4.1 se puede apreciar la distribucin de los componentes que forman parte de la Arquitectura RBAC orientada a servicios y como las capas controlan la interaccin entre ellos, y sus interfases.
24
Captulo 4- Presentacin de la Arquitectura Propuesta
Figura 4.1 Arquitectura RBAC Orientada a Servicios
4.2.1 Descripcin de las capas de la Arquitectura Es importante en este punto, ampliar la descripcin de la estructura de nuestro enfoque, presentando el conjunto de componentes predefinidos que la conforman; las responsabilidades, colaboraciones y relaciones entre ellos. La capa de Aplicacin cumple un rol de integracin dentro del modelo propuesto en esta tesis. Es ac donde los desarrolladores deben implementar las interfaces necesarias para poder adaptar los servicios que ofrece la capa intermedia de nuestra Arquitectura a sus propios desarrollos, aprovechando la ventaja de estar frente a una arquitectura orientada a servicios basada en estndares, fcilmente integrable a cualquier lenguaje y plataforma. En la seccin 4.2.2.1 se muestra con un ejemplo como lograr esta integracin. En la Capa de Servicios de Control de Acceso se encuentran los componentes principales de la arquitectura. A continuacin describiremos la funcin de cada uno de ellos y como colaboran entre si. Comenzando por el componente Ejecutor, un servicio Web que acta de software intermedio entre la aplicacin cliente y el sistema RBAC. Su funcin principal es permitir o denegar a un sujeto, el uso de los recursos de la aplicacin, segn el/los rol/les que posea. Cada vez que el sujeto requiere acceso a un recurso o servicio, Ejecutor toma esta peticin y con la colaboracin de otros componentes del sistema RBAC, analiza el control de acceso. Dependiendo del perfil del sujeto, se conceder o negar el acceso. Una vez finalizado este paso, Ejecutor cede el control del proceso a la aplicacin cliente de manera totalmente transparente al usuario.
25
Ejecutor, por su interfaz simple y bien definida, permite ser fcilmente integrable en el desarrollo de una aplicacin, posibilitando de esta manera a los desarrolladores abstraerse de los problemas del control de acceso. Ms adelante, veremos cmo llevar a cabo esta integracin usando las bondades de la arquitectura SOA. El siguiente componente es el Conmutador de Polticas de Control de Acceso. Es un servicio Web que acta de interfaz entre Ejecutor y el propio servicio Web RBAC. Todo el intercambio de mensajes requeridos para llevar a cabo el control de acceso es configurado en el Conmutador. Esta separacin genera una independencia entre el mdulo Ejecutor y el sistema RBAC con respecto a las polticas de control propias de la empresa. En el Conmutador se definen la secuencia de pasos a seguir para acceder a la informacin relativa a los permisos que un par usuario-rol pueden tener. La puesta en ejecucin de este componente permite crear un mdulo para aplicar directivas personalizadas propias de una organizacin sin modificar el sistema RBAC existente. Para finalizar con los componentes de la Capa de Servicios de Control de Acceso nos encontramos con el Servicio Web RBAC, el cual interacta directamente con la Capa Infraestructura RBAC. De esta se obtiene informacin sobre roles, usuarios, autorizaciones y su configuracin dentro de la organizacin. Este servicio provee informacin de control de acceso al Conmutador cuando este ltimo lo requiera. Adems incluye un manejador de sesiones, del cual se recupera informacin del usuario en tiempo de ejecucin para gestionar y dar soporte a las restricciones de acceso a los recursos, tal como la separacin esttica y dinmica de tareas o jerarqua de roles, como as tambin informacin de conexin y log de auditoria en caso de ser requerido. La ltima capa de la arquitectura es la Capa de Infraestructura RBAC, la cual provee a los administradores de un mdulo de configuracin para definir cuentas de usuarios, roles y autorizaciones, as como tambin establecer la jerarqua de roles y la separacin de tareas entre estos. En esta capa se encuentran las Bases de Datos donde se mantienen las relaciones y restricciones que hacen al propio sistema RBAC, como por ejemplo las dependencias usuario rol y rol autorizacin. En el Capitulo 5 detallamos un mdulo de Configuracin RBAC donde especificamos como llevar a cabo estas tareas de mantenimiento. 4.2.2 Distribucin de los componentes de la Arquitectura RBAC Para entender mejor la estructura de la arquitectura, mostramos mediante un diagrama de componentes y distribucin una posible ubicacin fsica de las partes del modelo presentado en esta tesis. La figura 4.2 detalla este diagrama, representando las partes ms importantes de la arquitectura y como estn relacionadas.
26
Figura 4.2 Diagrama de Componentes y distribucin
En el diagrama podemos observar que existe una alta interaccin entre los Servicios Web Ejecutor, Conmutador y RBAC en el momento de resolver el acceso a un recurso, que es totalmente transparente para el usuario final de la aplicacin. La pregunta es: Por qu es necesaria la existencia de tantos componentes en vez de centralizar todo en uno? La respuesta se basa en aprovechar las ventajas de una arquitectura SOA [15] para lograr una alta modularizacin que ayude a simplificar la resolucin de los distintos problemas que puedan ocurrir en la gestin del control de acceso; facilitando al mismo tiempo una integracin eficiente de los componentes de la arquitectura a un proyecto de software. Por ejemplo, uno de los propsitos de separar los componentes Servicio Web Ejecutor y Servicio Web Conmutador es disponer de ms de una implementacin de este ltimo componente, y de esta manera poder independizar la secuencia de operaciones a ejecutar segn las diferentes polticas de acceso que una organizacin puede disponer en distintos momentos. La modularizacin aplicada al diseo de la arquitectura propuesta en esta tesis logra esta separacin entre ambos componentes permitiendo adaptar fcilmente cambios en las polticas de la organizacin sin necesidad de manipular al Servicio Web Ejecutor que est directamente relacionado con la aplicacin empresarial. Adems el Servicio Web Ejecutor, provee a los desarrolladores una interface simple para ser usada a la hora de validar un acceso a una aplicacin, por lo que no es necesario que el analista deba conocer como el componente Servicio Web Conmutador coopera con el Servicio web RBAC para resolver las distintas problemticas a la hora de validar el acceso a un recurso. De esta manera el Servicio Web RBAC es el nico responsable de acceder a las base de datos y recuperar informacin relativa a usuarios, roles y autorizaciones, y responder a otros componentes cuando requieran este tipo de datos. Este desacoplamiento logra evitar que otras partes tengan que acceder a las base de datos RBAC explcitamente encapsulando los mtodos y conexiones al repositorio de
27
datos en este componente alcanzando as un mayor nivel de seguridad de la informacin. Por ltimo podemos destacar que con esta distribucin de los componentes se consigue una mayor flexibilidad en las tareas de desarrollo, pues como se mencion anteriormente, una arquitectura orientada a servicios permite reutilizar los mdulos existentes para generar nuevas aplicaciones. Como consecuencia tambin se reducen los costos de mantenimiento. 4.2.3 Interaccin entre los componentes de la Arquitectura RBAC Para expandir el campo de visin de nuestro Framework, mostramos mediante diagramas de secuencia como los objetos que componen la arquitectura interactan entre si mientras transcurre el tiempo. En la Figura 4.3, presentamos un primer diagrama de secuencias que resume la mecnica de interaccin entre los servicios para generar primero una sesin, y posteriormente resolver el acceso a algn recurso del sistema, es decir la secuencia lgica propia del sistema RBAC para resolver las diferentes restricciones de acceso. Como una de las ventajas de nuestro enfoque es que el desarrollador que lo utilice no necesita tener conocimiento de las colaboraciones internas entre los servicios de la Capa de Servicios de Control de Acceso, por ser estas transparentes a l, las instancias de los servicios Conmutador y RBAC no forman parte de este primer diagrama. Como ejemplo de estas colaboraciones internas podemos citar los posibles conflictos de intereses que puedan ocurrir durante una sesin.
Figura 4.3 Diagrama de secuencias de interaccin entre componentes
28
Continuando con nuestro escenario, describimos la secuencia de mensajes, que van de un objeto a otro, a travs del tiempo: 1El Sujeto intenta iniciar sesin en el sistema, ingresando un usuario y contrasea, considerando que este usuario final del sistema fue primero dado de alta en RBAC y asignado a un rol vlido. El Sistema debe llamar al servicio Web RBAC para validar a este usuario en RBAC. El Servicio Web RBAC ejecuta tres procesos. Primero valida el par usuario contrasea, luego busca el rol de este usuario. En caso que est todo bien, el mdulo crea una sesin RBAC. El Servicio Web RBAC devuelve un mensaje de acceso otorgado. El Sistema crea su propia sesin para este usuario. El Servicio devuelve un mensaje de acceso otorgado al Sujeto. El Sujeto intenta acceder a un recurso del sistema. El Sistema llama al Servicio Web Ejecutor para validar el acceso Ejecutor verifica el acceso. Tanto el Servicio Web RBAC como el Servicio Web Conmutador colaboran con Ejecutor para resolver este punto en forma transparente para el Sujeto. Ejecutor devuelve un mensaje de acceso otorgado al sistema. El Sistema habilita el acceso al Sujeto sobre el recurso en cuestin.
23-
456789-
1011-
En el diagrama de secuencia de la figura 4.4 ampliamos el escenario anterior para mostrar la interaccin que hay entre los Servicios Web Ejecutor, Conmutador y RBAC para resolver el acceso a un recurso. Nos enfocamos en detallar aun ms cmo se relacionan estos componentes, teniendo en cuenta no solo la perspectiva del ingeniero de software que hace uso de este framework, sino tambin en la cadena de colaboraciones que existen entre ellos para llevar a cabo el control de acceso a un recurso.
29
Figura 4.4 Diagrama de secuencias de interaccin entre componentes
12-
El Sujeto intenta acceder a un recurso del sistema. El Sistema invoca al mtodo puedeEjecutar del Servicio Web Ejecutor para validar el acceso, pasando por parmetros el usuario, clave, rol, recurso y operacin. As mismo, el Servicio Web Ejecutor llama al mtodo verificarAcceso del Servicio Web conmutador, pasando por parmetro el usuario, clave, rol, recurso y operacin. El Servicio Web Conmutador lanza una secuencia de operaciones, para validar el acceso. La primera de ellas es llamar al mtodo devolverRoles del Servicio Web RBAC para obtener as una lista de roles correspondientes a la jerarqua de roles del usuario. En esta ocasin se pasa por parmetros el usuario y clave. El servicio Web RBAC llama as mismo la operacin BuscarRolesJerarqua, accediendo a la base de datos RBAC para obtener dicha informacin. El Servicio Web RBAC devuelve al Conmutador la lista de roles requerida. El servicio Web Conmutador llama ahora al mtodo tieneOperacion por cada uno de los roles de la lista obtenida anteriormente, pasando por parmetro un rol, recurso y operacin. Esto se repite hasta verificar si alguno de los roles tiene la autorizacin requerida por el usuario. Por cada invocacin del paso anterior, el Servicio Web RBAC llama a la operacin verificarAutorizacion, que accede a la base de datos RBAC para consultar si el rol pasado por parmetro puede ejecutar la operacin correspondiente sobre el recurso, ambos datos tambin pasados por parmetro.
3-
4-
5-
67-
8-
30
910-
El Servicio Web Conmutador recibe como respuesta que existe la autorizacin requerida. Como ltimo paso de esta secuencia de operaciones, Conmutador invoca la operacin separacionDinTareas para cerciorarse, antes de activar el rol correspondiente, que no exista algn posible conflicto de intereses con otros roles activos del usuario. En esta ocasin pasa por parmetros el rol y el usuario. Servicio Web RBAC llama a s mismo la operacin verificarSeparacionDin con rol y usuario como parmetros. Accede a las base de datos RBAC y verifica en la Lista de Roles Activos del usuario (ARS) que no exista exclusividad mutua entre este rol y los ya activos en la sesin. Luego procede a activar el rol pasado por parmetro. El Servicio web Conmutador recibe una notificacin que no existen conflicto de intereses. El Servicio Web Ejecutor recibe un aviso de acceso otorgado. Ejecutor devuelve un mensaje de acceso otorgado al sistema. El Sistema habilita el acceso al Sujeto sobre el recurso en cuestin.
11-
12131415-
En el Anexo A est disponible una implementacin de nuestra Arquitectura desarrollada en Java 6 [11], donde se detalla cada uno de los componentes y operaciones. Describimos las principales lneas de cdigo que consideramos relevantes para que sirva de gua a un programador que quiera aplicar nuestro Framework en su propio proyecto de software. A continuacin vamos a explicar mediante un ejemplo prctico como llevar adelante esta tarea. 4.2.4 Ejemplo prctico de cmo integrar nuestra Arquitectura RBAC Orientada a Servicios a un desarrollo en Netbeans 6.1 Uno de los objetivos principales de esta tesis es lograr minimizar el esfuerzo invertido en la gestin del control de acceso por parte de los desarrolladores, ofrecindoles un Framework fcil de adaptar e integrar a un proyecto de software. Por lo tanto, el desarrollador de una aplicacin, como por ejemplo el Laboratorio Remoto [5], solo tendr que hacer uso de los servicios que nuestra arquitectura le provee, y al estar basada en servicios Web, no tendr que preocuparse de cmo estos componentes estn implementados. A los efectos de poder llevar adelante una discusin sobre las ventajas mencionadas en el prrafo anterior, mostramos a continuacin un ejemplo prctico de cmo integrar nuestra Arquitectura RBAC Orientada a Servicios a un proyecto denominado Laboratorio Remoto, usando como ambiente integrado de desarrollo (IDE, Integrated Development Environment) Netbeans 6.1 [10]. Tomando como gua el diagrama de secuencias visto en la figura 4.4 , la integracin bsicamente consiste en adaptar los dos servicios Web de la Capa de Servicios de Control de Acceso: el servicio RBAC y el servicio Ejecutor. El primero ser invocado en el momento de crear una sesin dentro del sistema o aplicacin que se est
31
desarrollando. El segundo en cambio, ser llamado cada vez que sea necesario evaluar el acceso a algn recurso del sistema. La primera actividad de la Integracin, es crear las referencias a los servicios Web RBAC y Ejecutor que actuarn de Proxy en el Proyecto Netbeans [10]. Estas referencias son llamadas clientes de servicios Web (Web service Client) y sirven como representante del servicio remoto para poder consumir las operaciones que este ofrece. Estos clientes luego de creados, pueden ser testeados para conocer que las operaciones son consumidas con xito. En la figura 4.5 se muestra como realizar la creacin de estos Clientes en Laboratorio Remoto.
Figura 4.5 Crear un Web Service Client en Netbeans 6.1
En la carpeta Web Service References del proyecto se pueden observar, como muestra la Figura 4.6, las referencias a servicios Web creadas: Ejecutor y RBAC.
Figura 4.6 Web Service Clients creados en el proyecto Laboratorio
Una vez creados y testeados los clientes, se estar en condiciones de consumir las operaciones de los servicios del mdulo RBAC. Como segunda actividad entonces, se invoca a la operacin buscarRol de la referencia RbacService. En la Figura 4.7 se muestran las posibles operaciones que RbacService ofrece.
32
Figura 4.7 Operaciones del Servicio Web RBAC
Una vez seleccionada la operacin buscarRol, Netbeans [10] generar el siguiente cdigo:
Podemos ver que el IDE ha creado un objeto port que a partir de ahora servir de Proxy para consumir las operaciones. El llamado a esta operacin se deber situar en la parte del cdigo del Proyecto Laboratorio que se encarga de permitir el login o ingreso de usuarios a la aplicacin. Como un ejemplo particular, se llama a la operacin buscarRol de la siguiente forma:
De una manera muy simple se ha logrado implementar la validacin del ingreso de un usuario a la aplicacin Laboratorio Remoto. Tambin, de forma transparente, se ha creado una sesin RBAC ligada al usuario, que permanecer activa mientras dure la sesin del mismo en la aplicacin, y servir como soporte en los distintos controles de acceso. Como tercera actividad, se debe evaluar el acceso a los recursos del sistema haciendo uso del servicio Web Ejecutor. Considerando que se ha creado y testeado el cliente Web, se est en condiciones de invocar a la operacin puedeEjecutar de Ejecutor, para otorgar o denegar el acceso. Ser una tarea del desarrollador, decidir donde es ms conveniente realizar la invocacin, dependiendo tambin del lenguaje que est utilizando o las facilidades que le puedan llegar a ofrecer el IDE de desarrollo.
33
Una posible estrategia es evaluar el acceso a un recurso en el momento de su creacin. En Netbeans [10] por ejemplo, se puede hacer uso del evento Pre creation code para invocar a puedeEjecutar, dndole acceso al usuario solo a aquellos objetos permitidos en su perfil. Esta estrategia de implementacin se usa por ejemplo, para mostrar los tems de mens a los que puede acceder un usuario. Esta estrategia en cambio no servir, en caso de ser necesario evaluar el acceso a un recurso en tiempo de ejecucin. Para esta situacin el acceso debe ser evaluado al momento de aplicar alguna accin sobre el objeto, por ejemplo, cuando se le hace un clic con el Mouse o se quiere dar de algn modo referencia sobre l. En definitiva, nuestra arquitectura no pone restricciones sobre el uso de las operaciones de los servicios que esta posee, el desarrollador es libre de aplicar las mejores prcticas de programacin para resolver el control de acceso en su proyecto de la manera ms eficiente posible. Continuando con la tercera actividad, resolver el acceso a un recurso, se debe crear el Proxy como un objeto global al sistema, para hacer uso de este cuando se invoque a alguna operacin de Ejecutor. En primer lugar, se crea el Proxy de Ejecutor denominado portEjecutor como instancia global del cliente Web creado anteriormente. En Segundo lugar, se crea una instancia del servicio Ejecutor y se usa a portEjecutor, como referente de este servicio.
El objeto portEjecutor ahora podr ser usado todas las veces que sea necesaria aplicar alguna operacin del servicio Web Ejecutor, en especial puedeEjecutar para verificar el acceso a un recurso. El siguiente cdigo es un ejemplo de como evaluar el ingreso a un recurso, especficamente a un tem de men de la aplicacin Laboratorio.
Capitulo 5
Mdulo de Configuracin RBAC
El Mdulo de Configuracin RBAC es una parte importante del Framework propuesto en esta tesis. Est disponible para los administradores que quieran configurar la distribucin de roles, usuarios y autorizaciones, otorgando la posibilidad de poder definir jerarqua de roles, adems de restricciones de acceso como los son la exclusividad mutua dinmica y esttica de tareas. La construccin de este mdulo tiene como objetivo agilizar aun ms la salida a produccin de un proyecto de software, pues est disponible para ser adaptado fcilmente a cualquier aplicacin empresarial. En este captulo presentamos la implementacin de este modulo hecho en Java 6 [11] y MySql [9] tomando como base para la construccin del mismo las reglas vistas en la seccin 3.5 del captulo 3, con el fin de garantizar una correcta configuracin de usuario, roles, autorizaciones y relaciones entre estas entidades.
5.1 Configuracin RBAC

En esta seccin vamos a considerar primero algunas pautas generales para planificar la distribucin RBAC en una organizacin, con el fin de lograr minimizar los errores o posibles conflictos que puedan llegar a ocurrir en la implementacin del control de acceso. 5.1.1 Planificacin de la distribucin de RBAC Consideramos importante tener en cuenta los siguientes pasos antes de comenzar a crear los roles y autorizaciones en la distribucin RBAC [6]: 1. Planificar los roles para los usuarios. 2. Planificar las autorizaciones para los roles. Las siguientes secciones describen estos pasos ms detalladamente. 5.1.1.1 Planificacin de los roles Planificar un conjunto adecuado de roles para los usuarios de un sistema constituye el primer paso fundamental en la distribucin de RBAC. En algunas organizaciones ya existe este conjunto de roles, que se puede volver a utilizar al configurar el control de acceso. Lo ms habitual es que sea necesario disear los roles segn las tareas existentes asociadas a los usuarios de una organizacin. A travs de diferentes tcnicas como encuestas, casos de uso, anlisis de las tareas del personal de la organizacin, comprender bien el funcionamiento de la organizacin, conocer el tipo de sistemas que se utilizan en cada sector, preguntarse quienes pueden hacer qu cosas y quines deben hacer qu cosas; se puede determinar con mayor
5.1 Configuracin RBAC
35
precisin las tareas que se deben realizar en cada sector de la misma y as lograr distinguir los roles que cumplen las personas que trabajan en una empresa. Hay que tener en cuenta las siguientes pautas al disear los roles [6]: Debe haber un nmero considerablemente inferior de roles respecto al nmero total de usuarios del sistema. Si cada usuario requiere un rol especial, entonces no ser posible beneficiarse de toda la administracin simplificada relativa al uso de roles.

Los roles deben corresponder con las funciones organizacionales reales de los usuarios. Los usuarios pueden tener varias funciones y, por lo tanto, hay que disear algunos roles simplemente con vistas a agrupar las autorizaciones comunes a varias funciones empresariales. Con este enfoque, se pueden disear los roles jerrquicamente a fin de incluir distintas funciones mediante la inclusin de las autorizaciones correspondientes.
5.1.1.2 Planificacin de las autorizaciones para los roles Una vez definidos los roles de la organizacin, podemos proceder a planificar las autorizaciones asociadas a cada uno de ellos. Si las funciones de los roles coinciden con la jerarqua de autorizaciones ya existente, la asignacin de las autorizaciones se convierte en una tarea sencilla. Pero, si la jerarqua de autorizaciones existente no coincide con los roles, la definicin de las autorizaciones asociadas a cada rol es una tarea ms compleja. Consideramos los siguientes pasos a modo de ayuda [6]: 1. Obtener una lista de los servicios del sistema que se utilizan habitualmente en cada rol. 2. Comparar estos servicios con los de la base de datos RBAC. 3. Si se encuentran entradas coincidentes despus de realizar los pasos anteriores, utilizar estas entradas como gua para asignar las autorizaciones.
5.2 Base de Datos RBAC

En esta seccin presentamos un diagrama Entidad Relacin (figura 5.1) que muestra el modelado de la base de datos RBAC construida para esta tesis y por el que nos hemos basado para implementar el Mdulo de Configuracin RBAC. En l podemos observar el diseo de las entidades relevantes para el sistema RBAC as como sus interrelaciones y propiedades.
36
Capitulo 5-Mdulo de Configuracin RBAC
Figura 5.1 Diagrama Entidad Relacin para el modelado de base de datos RBAC
5.3 Empleando el Modulo de Configuracin RBAC
37

Para proveer de un enfoque ms detallado sobre el uso del Mdulo de Configuracin RBAC, vamos a mostrar a continuacin las principales actividades y operaciones que se pueden efectuar. 5.3.1 Configuracin de Roles, Usuarios y Autorizaciones El objetivo principal de la creacin del mdulo de configuracin RBAC es proporcionar una herramienta simple para que asista al administrador en la distribucin de un modelo RBAC grado 3 (cuyas caractersticas hemos analizado en el captulo 3 seccin 3.4). Para tal fin nos planteamos encarar la configuracin con los siguientes tres pasos: 1. Configurar los roles. 2. Configurar los usuarios. 3. Configurar las autorizaciones. 5.3.2 Configuracin de los Roles La configuracin de los roles para los usuarios es un proceso que consta de las siguientes etapas [6]: 2. Crear los roles. 3. Establecer las restricciones a los roles. 4. Asignar los roles a los usuarios o grupos. Navegando a travs de la interface de usuario de nuestro modulo de Configuracin RBAC, dentro de la seccin Administrar Roles, tenemos las siguientes opciones de men: Agregar un Rol Eliminar un Rol Jerarqua de Roles Lista Mutuamente Exclusiva Esttica de roles Lista Mutuamente Exclusiva Dinmica de roles
Vamos a ir describiendo brevemente el alcance de cada una de estas opciones. 5.3.2.1 Agregar un Rol En el panel de Alta de un rol, como muestra la figura 5.2, hay que especificar adems del ID y Descripcin del rol, una cardinalidad, la cual, como se explica en el captulo 3 seccin 3.4, sirve de restriccin al momento de asignar un nuevo usuario a dicho rol. Por ejemplo, algunos roles necesitan un mayor control de la distribucin de los permisos cuando una organizacin, por razones de seguridad, requiere que no se pueda crear ms de un usuario para el rol Administrador. As de esta manera configurando este rol con una cardinalidad igual a 1 estaramos garantizando esta restriccin.
38
Figura 5.2 Formulario de Alta de Roles
5.3.2.2 Eliminar un Rol El sistema adems permite quitar roles innecesarios contemplando que no est ningn usuario vinculado a dicho rol y que ningn otro rol dependa de este en la Jerarqua de Roles. En la figura 5.3 se muestra de manera sencilla como podemos eliminar un rol de nuestro esquema de roles, con solo seleccionarlo y presionar Eliminar.
Figura 5.3 Formulario para Eliminar un Rol
5.3.2.3 Jerarqua de Roles Una vez que tenemos definido el conjunto de roles en nuestra organizacin, debemos identificar aquellas operaciones superpuestas entre cada uno de ellos, y tambin aquellas operaciones que son nicas para cada rol. Esta tarea aade la posibilidad de modelar una jerarqua de roles de forma que se puedan realizar generalizaciones y especializaciones en los controles de acceso y facilitar la modelizacin de la seguridad en sistemas ms complejos.
39
Nuestro mdulo de configuracin RBAC permite configurar fcilmente una Jerarqua de Roles de manera natural, indicando el rol padre y la relacin con uno o ms roles hijos, como muestra la figura 5.4:
Figura 5.4 Formulario para Configurar la Jerarqua de Roles
Esta especializacin y generalizacin se cumple dinmicamente mediante una funcin recursiva que se encuentra implementada en el servicio web RBAC (en el Anexo I est disponible una implementacin de esta funcin). La idea es que dicha operacin recorra el rbol jerrquico de roles, estableciendo como nodo de partida el rol que fue asignado al usuario, e ir verificando a partir de este, y en todos los nodos descendientes, si posee la autorizacin planteada segn el caso. Por ejemplo, en caso que un sujeto necesite hacer uso de algn recurso del sistema, pero dicha autorizacin no est relacionada directamente con el rol que fue asignado, el sistema verificar si en algn rol descendiente la posee. Esta funcin es totalmente transparente tanto para el usuario final como tambin para el programador que hace uso del Framework. 5.3.2.4 Separacin esttica y dinmica de responsabilidades y tareas Para finalizar con la configuracin de roles de nuestro mdulo de configuracin RBAC, solo nos queda por indicar como generar las relaciones mutuamente exclusivas estticas y dinmicas que hay entre ellos. Estas restricciones tienen como finalidad hacer cumplir las limitaciones entre los roles, tal cual vimos en el captulo 3. En algunas organizaciones es permisible para un usuario ser miembro de dos roles los cuales no constituyen un conflicto de intereses cuando actan independientemente, pero introducen ciertas consideraciones cuando se permite que acten simultneamente. Nuestro mdulo RBAC provee a los administradores con la capacidad de imponer una poltica especfica de la organizacin en cuanto a la Separacin Dinmica de Tareas. Como vemos en la figura 5.5, el rol Alumno1 tiene una relacin mutuamente exclusiva dinmica con respecto al Rol Alumno2, lo que quiere decir que un usuario vinculado al rol Alumno1 no puede ser vinculado dinmicamente al rol Alumno2. De lo contrario, si un usuario tiene asignado el rol Alumno2, tambin tendr habilitado los privilegios del rol Alumno1, siempre y cuando la jerarqua de roles as lo permita; para eso el rol Alumno1 debe ser descendiente del rol Alumno2.
40
Esta restriccin se cumple mientras la sesin se encuentre activa durante el tiempo de ejecucin de la misma, y es soportada por la lista de roles activos que est ligada a la sesin de un sujeto, cuya funcin es registrar los roles que va activando el usuario en tiempo de ejecucin.
Figura 5.5 Formulario para Configurar la Separacin Dinmica entre Roles
Con la Separacin Esttica de Tareas se provee la capacidad de tratar potenciales conflictos de intereses en el momento de asociar un usuario dentro del rol.
Figura 5.6 Formulario para Configurar la Separacin Esttica entre Roles
En la figura 5.6 vemos que el Rol ADMIN tiene una relacin mutuamente exclusiva Esttica con el rol Alumno1, esto quiere decir que un usuario que tiene asignado el rol ADMIN no se le puede otorgar luego el rol Alumno1. Esta es una restriccin que se tiene en cuenta en el momento de asignacin de roles, y la cual se va a cumplir en todo momento durante la sesin de un usuario. Una vez definido los roles vlidos y las relaciones entre ellos, procedemos a asignarlos a uno o varios usuarios como veremos mas adelante. Primero indicamos como crear los usuarios.
41
5.3.3 Configuracin de los Usuarios La gestin de usuarios en el mdulo RBAC es muy simple. El alta solo requiere de una serie de datos personales y una contrasea que servir de login en el sistema con el fin de crear la sesin. En la baja simplemente se selecciona el usuario y se elimina. En la figura 5.7 se puede ver fcilmente como llevar a cabo estas acciones.
Figura 5.7 Formularios de Alta y Baja de Usuarios
5.3.3.1 Asignacin de los roles a usuarios Separar la creacin de roles de la asignacin de los mismos ofrece las siguientes ventajas [6]: Que sea necesario crear los roles antes de asignarlos garantiza que se detecten los errores al especificar los nombres de roles durante el proceso de asignacin de estos ltimos.
Permite que usuarios distintos realicen cada tarea. Por ejemplo, no es necesario que el mismo usuario cree los roles y los asigne.
En la figura 5.8 se muestra sencillamente como se puede ligar o desligar un usuario a un rol vlido. Cabe destacar, como vimos anteriormente, que un usuario puede ser miembro de un rol siempre y cuando la cardinalidad de dicho rol lo permita y la separacin esttica de tareas no detecte un posible conflicto de intereses. Estas validaciones las hace el mdulo automticamente, el administrador solo tiene que hacer la tarea de asignar usuarios a sus respectivos roles.
42
Figura 5.8 Formulario para Configurar la relacin Usuario Rol
5.3.4 Configuracin de las autorizaciones El procedimiento para configurar autorizaciones se parece al procedimiento para crear y asignar Roles, no obstante, las autorizaciones se componen de dos elementos: un Recurso y una operacin. La primer tarea que el administrador debe realizar es una lista de todos los recursos que comprende la aplicacin empresarial con sus respectivas operaciones, y as formar las posibles autorizaciones que luego sern asignadas a los roles. Es de mucha utilidad, como buena prctica, mantener un diccionario de datos de los procesos y objetos del sistema que se van creando con suficiente detalle para que sirva de gua de posibles recursos a tener en cuenta para generar las autorizaciones. La figura 5.9 muestra los formularios donde llevar a cabo el alta y baja de autorizaciones:
Figura 5.9 Formulario para Configurar las Autorizaciones
Captulo 6
Conclusiones y Trabajos Futuros
La tendencia del uso de tecnologas heterogneas en el desarrollo de aplicaciones distribuidas y/o colaborativas junto a un alto dinamismo en las polticas de control de acceso a los recursos y funciones del personal dentro de una organizacin est dando lugar a desarrollos de aplicaciones ms complejas, donde los ingenieros de software deben dar ms nfasis no solo a los requerimientos del negocio e infraestructura necesaria, sino tambin a los elementos relacionados a la seguridad del usuario dentro de estos sistemas. Motivados por esta realidad, desarrollamos nuestro enfoque para que asista a los analistas en la integracin de los aspectos de seguridad en el diseo y desarrollo de sistemas complejos. Especficamente nos centramos en presentar el diseo e implementacin de una Arquitectura RBAC orientada a Servicios.
En el presente Captulo, describimos las conclusiones que derivan de los resultados obtenidos de alcanzar los objetivos que nos propusimos. Mencionamos tambin los aportes y ventajas del presente trabajo y, los futuros trabajos que se pueden desarrollar analizndolos desde dos perspectivas: 1) Creacin de un servicio para dar soporte al modelo RBAC en el manejo de sesiones en un contexto global 2) creacin de herramientas que asistan a los desarrolladores en la utilizacin de nuestro enfoque cuando disean aplicaciones corporativas.
6.1 Resultados Arquitectura
obtenidos
del
diseo
de
nuestra
En base a los objetivos planteados al inicio de nuestra tesis, y valindonos de las bondades de una arquitectura orientada a servicios, hemos logrado disear un Framework tal que nos permita alcanzar integrabilidad, reusabilidad y bajo costo de mantenimiento. Con tal fin hemos presentado nuestra Arquitectura RBAC Basada en Servicios Web con la meta de conceder la posibilidad a un analista abstraerse de los problemas del control de acceso y dedicarse a resolver los problemas del negocio. Para esto hemos hecho una descripcin de los componentes del sistema, indicando como estn distribuidos, que funcin cumplen, y como colaboran entre s para llevar a cabo las diferentes operaciones de control de acceso a los recursos de una organizacin. Es importante destacar la distribucin de los componentes de la Arquitectura, donde nos preguntbamos porque separar las acciones del control de acceso en varios componentes en vez de centralizar todo en uno solo. Nos dimos cuenta que gracias a los estndares de la tecnologa SOA pudimos aplicar una modularizacin tal que nos permita separar los distintos aspectos y problemas en diferentes servicios Web fcilmente integrables, consiguiendo as un bajo costo de mantenimiento. De esta manera, el diseo de aplicaciones empresariales que se desarrolle bajo nuestro Framework, no solo conseguir resolver los problemas del control de acceso, sino tambin permitir disminuir los tiempos y costos del proyecto, agilizando la finalizacin y puesta en produccin del mismo.
44
Captulo 6- Conclusiones y Trabajos Futuros
Para dar ms enfoque sobre el alcance de la Arquitectura, hemos desarrollado dos escenarios, representados mediante diagramas de secuencia, con el fin de precisar aun ms el funcionamiento de los componentes en un contexto de ejecucin. Basndonos en estas representaciones pudimos dar al lector un espectro ms amplio sobre las colaboraciones entre los componentes, otorgando ms nocin sobre los aspectos ms importantes en el funcionamiento de cada uno de ellos y sus responsabilidades. Para que los analistas y diseadores de aplicaciones organizacionales tengan un conocimiento mas preciso sobre como hacer uso de nuestro Framework, hemos desarrollado un ejemplo prctico en Java que sirva de gua para tal fin. Con la salvedad de, sin perder de vista los pasos a seguir para hacer uso de los componentes, no poner restricciones a los programadores en como adaptar nuestra Arquitectura a un modelo propio. Tal como hemos sealado en los objetivos de la tesis, y luego de haber analizado el ejemplo prctico nombrado anteriormente, hemos expuesto lo fcilmente integrable que es nuestra Arquitectura a un proyecto de software. En este punto tambin es importante destacar la construccin del Mdulo de Configuracin RBAC. Consideramos interesante, adems de proporcionar un framework fcil de usar, dejar a disposicin de los analistas una aplicacin para que puedan gestionar toda la informacin relativa a roles, usuarios y autorizaciones, permitiendo agilizar aun mas la finalizacin y puesta en produccin de sus proyectos de software. Para finalizar con esta seccin, nos queda por enfatizar sobre la implementacin hecha en este trabajo de tesis, mostrada en detalles en el Anexo A. Consideramos importante plasmar el diseo de la Arquitectura hecho en esta tesis en base a una implementacin concreta usando el lenguaje Java. De esta manera creemos que, en base a esta experimentacin, quedan forjados todos los conceptos vistos en esta tesis. Si bien los escenarios planteados en el Captulo 4 contribuyen a conocer mejor el funcionamiento de nuestra Arquitectura, opinamos que es de gran ayuda para los desarrolladores fijar los conceptos en una implementacin detallada. De todo el trabajo realizado en esta tesis, concluimos que hemos elaborado un instrumento muy til para los arquitectos y desarrolladores de aplicaciones. Concretamente nuestro enfoque les permite resolver de una manera eficiente los problemas del control de acceso sin interferir en sus propios modelos arquitectnicos, minimizando los riesgos de cambios futuros y disminuyendo gran parte de los tiempos y costos de un proyecto de software.
6.2 Trabajos Futuros

Del trabajo llevado a cabo en esta tesis, en esta seccin planteamos los trabajos futuros desde las siguientes dos perspectivas: 1) Gestin de las sesiones a travs de un servicio Web para dar soporte al modelo RBAC en un contexto global y, 2) creacin de herramientas case que de soporte en la utilizacin de nuestro enfoque para aumentar la productividad en el desarrollo de una aplicacin y reducir los costos. Consideramos que ambas perspectivas son importantes al fortalecimiento y completitud de nuestro enfoque.
6.2 Trabajos Futuros
45
1) Creacin de un servicio Web para dar soporte al modelo RBAC en el manejo de sesiones en un contexto global.
Tal como sealamos en la seccin 3.6 del captulo 3, donde destacamos alguna de las principales limitaciones del modelo RBAC, vamos a poner nfasis en el problema de la falta de control de las sesiones de usuarios en un entorno global. Creemos conveniente disear y desarrollar una herramienta Web que monitoree las sesiones para dar respuesta a los otros componentes en tiempo de ejecucin, as estos pueden tomar directivas ms exactas a la hora de analizar un acceso. Consideramos importante que nuestro enfoque debe acompaar estos nuevos requerimientos para seguir soportando con eficiencia las metas planteadas al inicio de nuestro trabajo
2) Creacin de herramientas que asistan a los desarrolladores en la utilizacin de nuestro enfoque cuando disean aplicaciones corporativas.
Dependiendo en la etapa en la que se encuentre el proceso de desarrollo de una aplicacin empresarial, nuestro enfoque puede ser utilizado por los analistas y diseadores en la construccin e integracin del control de acceso a los recursos del sistema. En este sentido, se puede construir alguna herramienta Case que de soporte a nuestro enfoque. Esta herramienta permitir al desarrollador modelar y construir la aplicacin, siguiendo los lineamientos arquitecturales de nuestro trabajo para integrar nuestro framework al proyecto de una manera eficiente.
Anexo A
Implementacin Propuesta de la Arquitectura
A los efectos de poder llevar adelante una discusin sobre las ventajas de nuestra Arquitectura RBAC (Descripta en el Captulo 4), mostramos en este Anexo una implementacin de los principales componentes desarrollados en lenguaje Java 6 [11] y MySql [9], usando como IDE de desarrollo Netbeans 6.1 [10]. El objetivo es poder conocer, mediante extracciones de cdigo de una implementacin concreta, como colaboran e interactan los componentes de la arquitectura RBAC. A continuacin nos enfocamos en exponer las principales partes del cdigo de los mtodos y operaciones desarrollados en esta implementacin, indicando en cada situacin como estn implementadas las diferentes acciones llevadas a cabo con el fin de resolver el acceso a un recurso en particular.
A.1 Implementacin del componente Ejecutor

El Servicio Web Ejecutor, como vimos en el captulo 4, es el componente ms visible de la arquitectura, por lo que vamos usar a este como punto de partida de la presentacin. Se muestra a continuacin la principal operacin de este componente que se llama puedeEjecutar, y que es consumida por la aplicacin cliente cada vez que es necesario resolver el acceso a un recurso. En la figura A.1 se puede apreciar que esta operacin requiere de cuatro parmetros:
Figura A.1 Parmetros de la operacin puedeEjecutar del servicio web Ejecutor
A.1 Implementacin del componente Ejecutor
47
usuario: sujeto activo de la sesin. clave: contrasea personal del usuario, que servir junto al usuario para obtener el rol de este sujeto. recurso: para poder verificar si el rol de este sujeto tiene acceso a este recurso. operacin: para verificar si el rol de este sujeto puede aplicar dicha operacin al recurso en cuestin.
La invocacin de la operacin puedeEjecutar generar el siguiente intercambio de mensajes SOAP entre la aplicacin y el servicio: Mensaje SOAP de entrada
Mensaje SOAP de salida
A continuacin se muestra parte del cdigo fuente del Servicio Web Ejecutor donde se describe principalmente aquellas lneas que nos sirven para comprender como esta implementada la operacin puedeEjecutar. Se puede apreciar que hace uso de una instancia de un objeto ejecutor que implementa en definitiva la lgica de la operacin en el servicio web.
48
Anexo A-Implementacin de la Arquitectura Propuesta
En (1) se visualiza la lnea de cdigo que realiza la llamada al mtodo ejecutar del objeto ejecutor. A continuacin se muestra la clase del objeto ejecutor que esta implementada dentro del servicio Web y posee la lgica del mtodo.
En la porcin de cdigo (2) se muestra como el Servicio Web Ejecutor crea una instancia de un Proxy del Servicio Web Conmutador, as este, mediante la operacin verificarAcceso, resuelve el acceso a un recurso en cuestin. El resultado de esta operacin ser retornado por el Servicio Web Ejecutor a la aplicacin que intent realizar el acceso a un recurso en particular. Para continuar con el hilo lgico de este caso de estudio, vamos a describir como est implementado el Servicio Web Conmutador y sus operaciones.
A.2 Implementacin del componente Conmutador
49

El Servicio Web Conmutador, toma las diferentes peticiones de Ejecutor y aplica una serie de operaciones internas contenidas dentro del mtodo verificarAcceso. La secuencia de ejecucin de estas operaciones es preestablecida por la organizacin, y el objetivo de esta es evaluar dinmicamente el acceso a un recurso segn las restricciones establecidas por las polticas de acceso vigentes en la organizacin, las cuales fueron fundadas previamente en el mdulo de Configuracin RBAC (visto en el Captulo 5). A continuacin repasamos los cdigos fuentes de las principales operaciones de este componente, donde describimos qu funcin cumple cada una, y cmo interactan con el resto de los componentes y/o servicios de la Arquitectura. Comenzamos con la operacin ms importante llamada verificarAcceso. En la figura A.2 se muestra un esquema donde se visualiza la estructura de esta operacin y sus parmetros.
Figura A.2 Parmetros de la operacin verificarAcceso del servicio web Conmutador
usuario: sujeto activo de la sesin. clave: contrasea personal del usuario, que servir junto al usuario para obtener el rol de este sujeto. recurso: para poder verificar si el rol de este sujeto tiene acceso a este recurso. operacin: para verificar si el rol de este sujeto puede aplicar dicha operacin al recurso en cuestin.
La invocacin de la operacin verificarAcceso generar el siguiente intercambio de mensajes SOAP entre ambos servicios Web: Mensaje SOAP de entrada
50
Mensaje SOAP de salida
El siguiente cdigo corresponde a la implementacin de esta operacin, donde se puede apreciar la instanciacin de un objeto conmutador que contiene la lgica necesaria para examinar el acceso.
En (3) se observa la creacin de una instancia de un objeto conmutador cuya clase Conmutador se encuentra implementada dentro del mismo servicio web de igual nombre. Con esta instancia se llama al mtodo puedeEjecutar que contiene la lgica que se detalla a continuacin. El resultado es devuelto al Servicio web Ejecutor mediante el intercambio de mensajes SOAP vistos anteriormente.
51
A partir de ahora se detalla las partes ms relevantes del cdigo fuente de la clase Conmutador:
4 6 5 7
En (4) podemos ver que conmutador llama as mismo el mtodo devolverRoles que se describe mas adelante, para obtener una lista con la jerarqua completa de los roles que tiene el usuario . En (5) vemos que por cada rol obtenido anteriormente, primero se verifica en (6) mediante el mtodo tieneOperacion si posee los privilegios necesarios para poder ejecutar la operacin indicada sobre el recurso, en otras palabras si el usuario posee la autorizacin que corresponde. En caso de ser as, antes de activar el rol y otorgar el acceso al recurso, en (7) se verifica que se cumpla la separacin dinmica de tareas, para controlar que no haya posibles conflictos de intereses. Para esto conmutador llama al mtodo separacionDinTareas, que se detalla ms adelante. Con respecto a la separacin esttica de tareas, recordemos que es una restriccin que se aplica en el momento de asignar un rol a un usuario, y no dinmicamente durante el hilo de ejecucin de una sesin. Esta restriccin es configurada en el Mdulo de Configuracin RBAC visto en el Captulo 5. En el siguiente cdigo se describe el mtodo devolverRoles de la clase Conmutador:
52
En (8) se observa como el objeto conmutador crea una instancia de un Proxy para el Servicio Web RBAC, y de esta manera consumir la operacin buscarRolesJerarquia para conseguir la lista de roles requerida, pasando como parmetros el usuario y la clave que sirven para identificar la sesin generada por este sujeto en la infraestructura RBAC. Mas adelante se muestra con mas detalle el Servicio Web RBAC que es el componente que asiste permanentemente al Servicio Web Conmutador para obtener informacin sobre roles, usuarios, autorizaciones y restricciones de las bases de datos RBAC. El siguiente mtodo a describir, para continuar con la secuencia de ejecucin, es tieneOperacion que fue referenciada en (6):
En este mtodo se puede observar como conmutador, nuevamente a travs de un Proxy, consume en (9) la operacin verificarAutorizacin del Servicio Web RBAC para conocer si el rol al que pertenece el sujeto tiene los privilegios para ejecutar la operacin en cuestin sobre el recurso. Para finalizar con la secuencia solo separacionDinTareas referenciado en (7): queda por describir el mtodo
10
El objeto conmutador nuevamente necesita del servicio Web RBAC para poder controlar que no exista un posible conflicto de intereses en el momento de activar el rol
53
correspondiente. Esta situacin es resuelta en (10) consumiendo la operacin verificarSeparacinDin pasando por parmetro el rol y el legajo, as de esta manera RBAC puede verificar que no haya exclusin mutua entre los roles activos de la sesin y el rol que se est por activar.
A.3 Implementacin del componente RBAC

Para concluir con la exposicin de los principales componentes de la Arquitectura propuesta, se muestra a continuacin descripciones de parte de cdigos fuente que implementan las operaciones del servicio Web RBAC, que es el componente que interacta directamente con la base de datos RBAC, y responde a las necesidades de Conmutador. En primer lugar se describen las operaciones que gestionan la creacin y finalizacin de las distintas sesiones que se van generando dinmicamente. Como vimos en el Captulo 4 seccin 4.2.2, la invocacin de estas operaciones se realiza en el momento que la aplicacin cliente genera un login en el sistema, disparando una serie de eventos que incluye buscar y validar el rol en RBAC y luego crear la sesin. En la figura A.3 se muestra un esquema donde se visualiza la estructura de la operacin iniciarSesionRBAC y sus parmetros.
Figura A.3 Parmetros de la operacin iniciarSesionRBAC del servicio web RBAC
usuario: sujeto activo de la sesin. clave: contrasea personal del usuario, que servir junto al usuario para obtener el rol de este sujeto. driver: driver de conexin a la base de datos RBAC dataBase: nombre de la base de datos RBAC usrDB: usuario de la Base de datos RBAC claveDB: clave del usuario de la Base de datos RBAC
La invocacin de esta operacin genera el siguiente intercambio de mensajes SOAP: Mensaje SOAP de Entrada
54
Mensaje SOAP de Salida
El siguiente cdigo muestra la implementacin de esta operacin del servicio web RBAC, el cual se analiza por partes:
55
11
12
13
En el cdigo fuente de esta operacin se destacan tres secciones. En (11) se crea una conexin a la base de datos RBAC usando como parmetros el driver, dataBase, usrDB y claveDB (explicados anteriormente en la figura 15). A partir de esta conexin se instancia un objeto statement que es utilizado para ejecutar consultas y actualizaciones en la base de datos. En (12) se destacan dos validaciones; en primer lugar se verifica que la clave del usuario pasada por parmetro sea la correcta, para luego chequear que exista un rol vlido para este usuario en RBAC. Si hasta ac todo es correcto, en (13) se procede a la creacin de la sesin para el usuario en cuestin; como ltimo paso se asocia los datos de conexin correspondientes a esta sesin. Para terminar con las operaciones que gestionan las sesiones RBAC, solo queda por describir la implementacin de la operacin finalizarSesion. En la figura A.4 se puede ver la estructura de parmetros necesaria:
56
Figura A.4 Parmetros de la operacin finalizarSesion del servicio web RBAC
usuario: sujeto activo de la sesin. clave: contrasea personal del usuario, que servir junto al usuario para obtener la sesin de este sujeto.
Mensaje SOAP de Salida (No genera mensaje de Salida, pues solo elimina los registros de la sesin en la base de datos RBAC). El cdigo de esta operacin es el siguiente:
14
En (14) se lleva a cabo la eliminacin de los registros de sesin en la base de datos RBAC en tres pasos. Primero se elimina el registro de sesin creado; luego se procede a limpiar la lista de roles activos (ARS) correspondientes al usuario en cuestin (la
57
funcin que cumple esta lista est desarrollada en el Capitulo 3 seccin 3.5; como ltimo paso se elimina el registro de conexin a la base de datos asociados a la sesin. Ahora damos lugar a las operaciones responsable de la verificacin y control de acceso a los recursos, con el objetivo de asistir y dar respuesta al componente Conmutador visto en la seccin anterior. A continuacin se da inicio con la descripcin de la operacin buscarRolesJerarquia, que es invocada por Conmutador en (8). La figura A.5 muestra la estructura de parmetros requerida para su invocacin:
Figura A.5 Parmetros de la operacin buscarRolesJerarquia del servicio web RBAC
usuario: sujeto activo de la sesin. clave: contrasea personal del usuario, que servir junto al usuario para obtener la sesin y el rol de este sujeto.
Mensaje SAOP de Salida
El siguiente cdigo muestra la implementacin de esta operacin que iremos analizando por partes:
58
15
16
17
59
En la porcin de cdigo de la operacin buscarRolesJerarqua referenciada por (15), se destaca el llamado a la funcin recursiva buscarRoles implementada en la misma clase. Previo a este llamado, se recupera el rol del usuario pasado por parmetro, que ser usado como nodo inicial para la bsqueda de la jerarqua para el usuario en cuestin. Una vez obtenida la lista de Roles, es retornada al Servicio Web Conmutador para continuar con el proceso correspondiente. En (16) se muestra el cdigo del mtodo buscarRoles, cuya finalidad es obtener una lista que representa la jerarqua de roles para el usuario en cuestin. Esta operacin se basa en recorrer en profundidad el rbol jerrquico establecido en el Mdulo de Configuracin RBAC (visto en el Captulo 5), cuyo nodo de partida es el rol pasado por parmetro en (15). A partir de ste se obtienen los roles descendientes para ir conformando la lista que ser retornada a la operacin buscarRolesJerarqua. Para esto, buscarRoles necesita de otra funcin referenciada en (17), buscarRolesHijos, que devuelve los roles descendiente directos del rol pasado por parmetro en (16). Continuando con el hilo de ejecucin, anteriormente en la referencia (9) hemos visto que el Servicio Web Conmutador consume la operacin verificarAutorizacion del Servicio Web RBAC. En la figura A.6 se muestra la estructura de parmetros vinculada a esta operacin:
Figura A.6 Parmetros de la operacin verificarAutorizacin del servicio web RBAC
rol: al cual est directamente asignado el usuario. recurso: para verificar junto a la operacin la existencia de una autorizacin vinculada al rol. operacin: para verificar junto al recurso la existencia de una autorizacin vinculada al rol.
El consumo de esta operacin genera el siguiente intercambio de mensajes SOAP: Mensaje SOAP de Salida:
60
Mensaje de SOAP de Entrada:
El propsito de esta operacin simplemente es validar que exista una autorizacin establecida entre el rol y el par recurso-operacin en la base de datos RBAC. En el Captulo 5 hemos visto como se configuran estas autorizaciones usando el Mdulo de Configuracin RBAC. El siguiente cdigo muestra la implementacin de esta operacin que analizamos de la siguiente manera:
18
En (18) se puede apreciar la ejecucin de una consulta sobre la base de datos RBAC en busca de la autorizacin correspondiente para el rol pasado como parmetro. En caso de encontrar dicha autorizacin, la operacin devuelve el valor booleano true al Servicio Web Conmutador, as este puede continuar con el hilo de ejecucin. En caso contrario, la operacin devuelve el valor false, generando luego una respuesta negativa hacia el Servicio Web Ejecutor, invalidando el acceso al recurso, o mejor dicho, inhabilitando al usuario aplicar dicha operacin sobre el recurso en cuestin. Para ir finalizando con la exposicin sobre la implementacin del servicio Web RBAC, queda por analizar la operacin verificarSeparacinDin que es consumida por Conmutador en (10) con el objetivo de resolver dinmicamente los riesgos de posibles conflictos de inters que se puedan generar en el momento de activar un rol.
61
En la figura A.7 se muestra la estructura de parmetros para esta operacin:
Figura A.7 Parmetros de la operacin verificarAutorizacin del servicio web RBAC
rol: el cual ser evaluado para su activacin y posterior agregado a la lista ARS correspondiente al legajo del usuario. legajo: que servir para identificar la lista ARS correspondiente.
El consumo de esta operacin genera el siguiente intercambio de mensajes SOAP: Mensaje SOAP de Salida:
Mensaje SOAP de Entrada
Cada vez que un usuario inicia una sesin RBAC en el sistema, se le asocia una lista ARS que ser mantenida mientras dure la sesin. A medida que el usuario va activando roles, estos se van agregando a esta lista que servir de soporte para el mtodo verificarSeparacinDin, as este pude verificar la separacin dinmica de tareas. Esta operacin es implementada con el siguiente cdigo que se analiza de la siguiente manera:
62
19
20
21
En la porcin de cdigo referenciada por (19) se pone a la vista la evaluacin de la exclusin mutua dinmica entre roles. Se lleva a cabo primero identificando los roles que fueron establecidos como mutuamente excluyentes al rol correspondiente al usuario de la sesin (esta alineacin es configurada previamente en el Mdulo de Configuracin RBAC que veremos en el siguiente captulo), y luego se comprueba que el rol pasado por parmetro no est contenido en esta lista obtenida previamente. En caso contrario, se identifica que hay un posible conflicto de intereses, se deniega la activacin del rol para este usuario. Si el rol no est dentro de los roles clasificados como excluyentes, se pasa al siguiente paso en (20) donde se procede a la actualizacin de la Lista de Roles Activos (ARS) para el legajo en cuestin donde se concreta la activacin del Rol y adems se retorna el valor booleano true indicando que no hay exclusin mutua. En (21) es la parte del cdigo que toma la excepcin que se produce al intentar insertar un registro en la lista de roles activos, pero el registro ya existe, generando un error de clave duplicada. En este caso, se infiere que el rol ya fue activado con anterioridad, y la operacin solo se limita a devolver el valor true al Servicio Web Conmutador.
Referencias
[1] desarrolloweb.com. Servicios Web en plataforma .NET. WSDL para la documentacin de Servicios Web. Disponible en: http://www.desarrolloweb.com/articulos/1581.php [2] desarrolloweb.com. Servicios Web en plataforma .NET. XML Web Services. Disponible en: http://www.desarrolloweb.com/articulos/1545.php [3] Francisco Lpez Luro, Leandro Bertogna, Laura Snchez, Jorge Rodrguez, Rodolfo Del Castillo: Infraestructura para Laboratorios de Acceso Remoto, Departamento de Ciencias de la Computacin, Universidad Nacional del Comahue, Neuqun 2009, Argentina. Disponible en: http://seadiuncoma.files.wordpress.com/2010/02/sanchez.pdf [4] Gabriel A. Domnguez Martn, Raul A. Cassolini. 1999. Universidad Nacional del Sur. Control de Acceso Basado en Roles. [5] Grosclaude Eduardo, Sznek Jorge, Ramos Garcia Vicente, Bertogna Leandro, Lpez Luro Francisco, Zanellato Claudio R.: Entorno Colaborativo sobre Laboratorios Remotos, 2006. Disponible en: http://ficcte.unimoron.edu.ar/wicc/Trabajos/V%20-%20tae/622Paper_V2.1.pdf [6] Hewlett-Packard Development Company L.P Gua del administrador de sistemas HPUX: Administracin de la seguridad. 2007. Disponible en: http://h20000.www2.hp.com/bizsupport/TechSupport/ [7] Hylde M. Ibarra Naranjo, Jos A. Maas Argem. Universidad Politcnica de Madrid, Espaa. RBAC: Alternativa actual para la realizacin de Control de Accesos a gran escala. [8] M. Snchez , B. Jimnez, F. L. Gutirrez, P. Paderewski, J. L. Isla. Departamento de Lenguajes y Sistemas Informticos Universidad de Granada.Departamento de Lenguajes y Sistemas Informticos Universidad de Cdiz. Modelo de Control de Acceso en un Sistema Colaborativo. [9] MySql, The world's most popular open source database. Disponible en: http://www.mysql.com/ [10] NetBeans, NetBeans IDE 6.1. Disponible en: http://netbeans.org/ [11] Oracle, Lenguaje Java. Disponible en: www.java.com [12] O'Reilly Media, Inc., 2010. http://onjava.com/pub/a/onjava/2005/01/26/soa-intro.html Disponible en:
[13] Ueli Wahli.Thomas Kjaer,Brett Robertson,Fumiko Satoh,Franz-Josef Schneider,Witold Szczeponik,Chris Whyley. WebSphere Version 6 Web Services Handbook Development and Deployment. July 2005. Disponible en: http://www.redbooks.ibm.com/portals/WebSphere
64
[14] W3C Web Services. Disponible en: http://www.w3.org/2002/ws [15] Wikipedia Enciclopedia de Contenido Libre Disponible en: http://es.wikipedia.org/wiki/Arquitectura_orientada_a_servicios#Literatura

Diseño e implementación de una Arquitectura RBAC basada en Servicios Web

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Diseño e implementación de una Arquitectura RBAC basada en Servicios Web

Uploaded by

Copyright:

Available Formats

UNIVERSIDAD NACIONAL DEL COMAHUE

FACULTAD DE ECONOMA Y ADMINISTRACIN

Matas Eloy Salcedo

Jorge Eduardo Sznek

NEUQUN Junio 2011

PGINA PARA LOS EVALUADORES

Lugar para la Fecha de la Evaluacin

Captulo 1-Introduccin al Proyecto

Captulo 1-Introduccin al Proyecto

2.1 Que es SOA?

Captulo 2-Tecnologa Subyacente

2.2 XML (Extensible Markup Language)

2.3 Qu son los Servicios Web?

2.3 Qu son los Servicios Web?

La figura 2.1 muestra cmo interacta un conjunto de Servicios Web:

Figura 2.1 - Los servicios Web en Funcionamiento

Captulo 2-Tecnologa Subyacente

2.4 SOAP (Protocolo Simple de Acceso a Objetos):

Figura 2.2 Composicin del mensaje SOAP

2.4 SOAP (Protocolo Simple de Acceso a Objetos)

2.5 WSDL (Lenguaje de Descripcin de Servicios Web)

Captulo 2-Tecnologa Subyacente

Figura 2.3 Estructura de un documento WSDL

2.6 UDDI (Universal Description Discovery and Integration)

2.7 Infraestructura para laboratorios de acceso remoto

2.7 Infraestructura para laboratorios de acceso remoto

3.1 Caractersticas del Modelo RBAC

3.1 Caractersticas del Modelo RBAC

3.2 Fundamentos del control del acceso

Captulo 3-RBAC (Control de Acceso Basado en Roles)

3.3 Simplificacin del control del acceso con roles.

3.4 Modelos RBAC y su evolucin

Figura 3.1 Modelos RBAC

3.4 Modelos RBAC y su evolucin

Figura 3.2 Modelo RBAC0

Captulo 3-RBAC (Control de Acceso Basado en Roles)

Figura 3.3 Modelo RBAC1

3.4 Modelos RBAC y su evolucin

Figura 3.4 Modelo RBAC2

Figura 3.5 Modelo RBAC3

3.5 Reglas del Sistema RBAC

Captulo 3-RBAC (Control de Acceso Basado en Roles)

3.5 Reglas del Sistema RBAC

Captulo 3-RBAC (Control de Acceso Basado en Roles)

3.6 Limitaciones del modelo

3.7 Conclusiones sobre el modelo RBAC

3.7 Conclusiones sobre el modelo RBAC

4.2 Arquitectura RBAC Orientada a Servicios

Captulo 4- Presentacin de la Arquitectura Propuesta

Figura 4.1 Arquitectura RBAC Orientada a Servicios

4.2 Arquitectura RBAC Orientada a Servicios

Captulo 4- Presentacin de la Arquitectura Propuesta

Figura 4.2 Diagrama de Componentes y distribucin

4.2 Arquitectura RBAC Orientada a Servicios

Figura 4.3 Diagrama de secuencias de interaccin entre componentes

Captulo 4- Presentacin de la Arquitectura Propuesta

4.2 Arquitectura RBAC Orientada a Servicios

Figura 4.4 Diagrama de secuencias de interaccin entre componentes

Captulo 4- Presentacin de la Arquitectura Propuesta

4.2 Arquitectura RBAC Orientada a Servicios

Figura 4.5 Crear un Web Service Client en Netbeans 6.1

Figura 4.6 Web Service Clients creados en el proyecto Laboratorio