tesis matias salcedo

8/4/2019 Tesis Matias Salcedo

1/76

UNIVERSIDADNACIONAL DEL COMAHUEFACULTAD DE ECONOMA Y ADMINISTRACIN

DEPARTAMENTO DE CIENCIAS DE LA COMPUTACIN

TESIS PARA LA CARRERALICENCIATURA EN CIENCIAS DE LA COMPUTACIN

Diseo e implementacin de una Arquitectura

RBAC basada en Servicios Web

Matas Eloy Salcedo

Jorge Eduardo Sznek

NEUQUN ARGENTINAJunio 2011


2/76

PGINA PARA LOS EVALUADORES

Calificacin:

Comentarios:

..

....

Lugar para la Fecha de la Evaluacin


3/76

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 ybrindndome todo su cario.


4/76

IV

PREFACIO

Esta tesis es presentada como parte de los requisitos finales para optar al gradoacadmico Licenciado en Ciencias de la Computacin, de la Universidad Nacionaldel Comahue y no ha sido presentada previamente para la obtencin de otro ttulo enesta Universidad u otras. La misma es el resultado de una investigacin llevada a caboen elDepartamento de Ciencias de la Computacin en el perodo comprendido entreDiciembre de 2008 y junio de 2011, bajo la direccin deJorge Eduardo Sznek

Matas Eloy SalcedoDEPARTAMENTO DE CIENCIAS DE LA COMPUTACIN

UNIVERSIDADNACIONAL DEL COMAHUENeuqun, . de Junio de 2011.


5/76

V

AGRADECIMIENTOS

Primero quisiera expresar mis agradecimientos a mi director de tesis, Jorge EduardoSznek, 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 hadado su mejor esfuerzo brindndome no solo el conocimiento necesario para miformacin como profesional sino tambin sus experiencias, motivaciones, ejemplos yconcejos que han acrecentado mi formacin como persona.

A todos ellos muchas gracias.


6/76

VI

RESUMEN

Como consecuencia de una mayor disposicin de las organizaciones en desplegar sus

procesos de negocio en sistemas colaborativos, las aplicaciones han evolucionadohacia servicios online de alta complejidad donde los recursos suelen estar distribuidosen diferentes plataformas y tecnologas. En este nuevo marco, las aplicaciones no solodeben cumplir con los objetivos funcionales por las que fueron creadas, sino ademssoportar con especial atencin los aspectos relacionados con la seguridad y el controlde acceso a los recursos.

Ante esta situacin el modelo RBAC es considerado por las organizaciones como unasolucin factible para gestionar el acceso a los recursos, pues da la posibilidad dereflejar de manera sencilla las funciones de los puestos de trabajo a roles en el sistemade informacin.

En esta tesis proponemos un enfoque para asistir a los desarrolladores en las tareas deintegrar los aspectos de seguridad y control de acceso a sus propios diseos durantelas etapas tempranas de un proyecto de software. Particularmente nos centramos en

presentar un framework arquitectnico que asocia las fortalezas del modelo RBAC ylas 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 losingenieros y diseadores de software.


7/76

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 onlineservices of high complexity where the resources are usually distributed in different platforms and technologies. In this new framework, the applications not only mustfulfill the functional objectives for which they were created, but also support withspecial 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 afeasible solution to manage the access to the resources, since it gives the possibility ofreflecting in a simple way the functions of the jobs into roles in the informationsystem.

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 theearly stages of a software project. Particularly we concentrated in presenting anarchitectural framework that combines the strengths of the RBAC model and theService Oriented Architectures.

The obtained architectural design essentially aims to diminish the costs of a softwareproject and to lighten the management tasks of the access control to the engineers andsoftware designers.


8/76

ndice generalCaptulo 1 .................................................................................................................... 1

Introduccin al Proyecto ........................................................................................... 11.1 Motivacin ........................................................................................................ 1

1.2 Objetivo ............................................................................................................ 31.3 Organizacin ..................................................................................................... 3

Captulo 2 .................................................................................................................... 5Tecnologia Subyacente ............................................................................................. 52.1 Que es SOA? ................................................................................................... 52.2 XML (Extensible Markup Language) ................................................................ 62.3 Qu son los Servicios Web? ............................................................................. 62.3.1 XML y Los Servicios Web ............................................................................. 72.4 SOAP (Protocolo Simple de Acceso a Objetos) ................................................. 82.5 WSDL (Lenguaje de Descripcin de Servicios Web .......................................... 9

2.6 UDDI (Universal Description Discovery and Integration)................................ 102.7 Infraestructura para laboratorios de acceso remoto........................................... 11

Captulo 3 .................................................................................................................. 12RBAC (Control de Acceso Basado en Roles) .......................................................... 123.1Caractersticas del Modelo RBAC................................................................... 123.2 Fundamentos del control del acceso ................................................................. 133.3 Simplificacin del control del acceso con roles ........... ..................................... 143.4 Modelos RBAC y su evolucin ....................................................................... 143.4.1 RBAC0 ......................................................................................................... 143.4.2 RBAC1 ......................................................................................................... 15

3.4.3 RBAC2 ......................................................................................................... 163.4.4 RBAC3 ......................................................................................................... 173.5 Reglas del Sistema RBAC ............................................................................... 173.6 Limitaciones del modelo ................................................................................. 203.7 Conclusiones sobre el modelo RBAC .............................................................. 20

Captulo 4 .................................................................................................................. 22Presentacin de la Arquitectura Propuesta ............................................................... 224.1 Porqu elegimos una Arquitectura Orientada a Servicios para el diseo denuestro Framework? .............................................................................................. 224.2 Arquitectura RBAC Orientada a Servicios ....................................................... 234.2.1 Descripcin de las capas de la Arquitectura .................................................. 244.2.2 Distribucin de los componentes de la Arquitectura RBAC .......................... 254.2.3 Interaccin entre los componentes de la Arquitectura RBAC .......... .............. 274.2.4 Ejemplo prctico de cmo integrar nuestra Arquitectura RBAC Orientada aServicios a un desarrollo en Netbeans 6.1 .............................................................. 30

Captulo 5 .................................................................................................................. 34Mdulo de Configuracin RBAC ............................................................................ 34


9/76

9

5.1 Configuracin RBAC ...................................................................................... 345.1.1 Planificacin de la distribucin de RBAC ..................................................... 345.1.1.1 Planificacin de los roles ........................................................................... 345.1.1.2 Planificacin de las autorizaciones para los roles ....................................... 355.2 Base de Datos RBAC ...................................................................................... 35

5.3Empleando el Modulo de Configuracin RBAC ............................................. 375.3.1 Configuracin de Roles, Usuarios y Autorizaciones...................................... 375.3.2 Configuracin de los Roles ........................................................................... 375.3.2.1 Agregar un Rol .......................................................................................... 375.3.2.2 Eliminar un Rol ......................................................................................... 385.3.2.3 Jerarqua de Roles...................................................................................... 385.3.2.4 Separacin esttica y dinmica de responsabilidades y tareas ..................... 395.3.3 Configuracin de los Usuarios ...................................................................... 415.3.3.1 Asignacin de los roles a usuarios ............................................................. 415.3.4 Configuracin de las autorizaciones .............................................................. 42

Captulo 6 .................................................................................................................. 43Conclusiones y Trabajos Futuros ............................................................................. 436.1 Resultados obtenidos del diseo de nuestra Arquitectura ................... .............. 436.2 Trabajos Futuros.............................................................................................. 44

Anexo A ..................................................................................................................... 46Implementacin de la Arquitectura Propuesta .......................................................... 46A.1 Implementacin del componente Ejecutor ...................................................... 46A.2 Implementacin del componente Conmutador ................................................ 49A.3 Implementacin del componente RBAC ......................................................... 53


10/76

ndice de figuras2.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 Roles5.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 operacinpuedeEjecutardel servicio Web Ejecutor

A.2: Parmetros de la operacin verificarAcceso del servicio Web Conmutador

A.3: Parmetros de la operacin iniciarSesionRBACdel servicio Web RBAC

A.4: Parmetros de la operacinfinalizarSesion 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


11/76

Captulo 1

Introduccin al ProyectoEn este Captulo presentamos el contexto sobre el que se desarroll nuestro trabajo. Eldetalle del contexto se instrumenta explicando la motivacin que dio origen a este

proyecto de tesis, incluyendo conceptos y definiciones preliminares relacionados a losobjetivos 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 actividadesrelacionadas al negocio. Esto provoca relaciones y dependencias complejas entre lasactividades y los usuarios que las realizan, por lo que para garantizar la seguridad de lainformacin, se hace necesaria una administracin que maneje diferentes niveles deacceso a las funciones o tareas, como as tambin a los recursos que estas implican.

Dada la tendencia de que las tecnologas heterogneas y plataformas diferentescontinuarn coexistiendo, las organizaciones optan por implementar sus procesos denegocios anticipndose a este nuevo cambio. La Web ha sido sin duda el medio mselegido para llevar a cabo este desafo, ayudando notablemente a mejorar la eficiencia yflexibilidad 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 tornanconsiderablemente ms complejas, por lo que los desarrolladores tendrn que invertirmayor esfuerzo no solo en lograr los objetivos del negocio, sino tambin en estosaspectos relacionados con la seguridad.

Las arquitecturas orientadas a servicio proveen una clara solucin para permitir quelos sistemas expongan su funcionalidad por medio de interfaces operablesestandarizadas, logran la modularidad apropiada y disminuyen el acople entre losmdulos con mayor interoperabilidad [12]. En este contexto, donde los servicios estndistribuidos, los usuarios finales tendrn que controlar su interaccin obteniendo la

informacin que desean en documentos XML generados dinmicamente. Diferentesusuarios pueden tener diferentes intereses e incluso diferentes niveles de accesos a esainformacin, y los servidores debern conocer con precisin qu datos concretos puedenleer y/o modificar y cules no. Por este motivo la arquitectura tendr que soportar uncontrol 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 muchodinamismo en las compaas, y es necesario ser capaz de definir un modelo de controlde acceso lo suficientemente flexible como para adaptarse a los cambios. El control de


12/76

2 Captulo 1-Introduccin al Proyecto

acceso es un elemento clave en la seguridad de un sistema y sirve como complementoimportante a la definicin de la interaccin entre los usuarios del sistema y, en el casode 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 laseguridad en sistemas a gran escala en grandes compaas. Es una tecnologa que estatrayendo gran atencin por su potencial para reducir la complejidad y el costo en laadministracin de la seguridad en grandes aplicaciones distribuidas. Este modelo

permite expresar de forma sencilla y natural la poltica de accesos a los recursos de laorganizacin, y adems se caracteriza por la nocin de que los permisos son asignados aroles, y no directamente a los usuarios, quienes son asociados luego a suscorrespondientes roles de acuerdo a su funcin en el sistema, relacionando de estamanera implcitamente los permisos a los usuarios.

El modelo RBAC incluye un conjunto de sesiones donde cada sesin es la relacinentre un usuario y un subconjunto de roles que son activados en el momento deestablecer dicha sesin. Cada sesin est asociada con un nico usuario y cada usuariotiene 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, sintener 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 deesta manera lograr integrar los aspectos de seguridad con los funcionales de unaorganizacin.

Consideramos tambin que durante el desarrollo de un sistema los costosrelacionados a los cambios en los requisitos o a la aparicin de nuevos requerimientosson una parte considerable del costo total del desarrollo. En nuestra opinin, esimportante poder llevar a cabo una integracin de los elementos de seguridad con elresto de los requerimientos o funcionalidades del sistema en etapas tempranas del

proyecto, pero sin interferir demasiado. Hacemos nfasis en esto porque los elementosrelacionados con la seguridad se dejan en muchos casos para etapas finales del procesode desarrollo provocando fuertes incrementos en el costo del producto final. Los temasde seguridad son tan importantes y complejos como para necesitar ser abordados desdelas primeras etapas del proyecto y con modelos que faciliten su adaptacin ydinamismo.

Por esta situacin nos enmarcamos en la tarea de proponer una arquitecturaespecfica que sirva a los desarrolladores adaptar fcilmente el control de acceso aldiseo de una aplicacin distribuida. Particularmente para nuestro caso de estudioutilizamos la aplicacin Laboratorio Remoto. Es un proyecto de investigacin desoftware para procesos colaborativos iniciado en el Departamento de Ciencias de lacomputacin, Universidad Nacional del Comahue [5].


13/76

1.2 Objetivo 3

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 puedanintegrar fcilmente el control de acceso a sus diseos y modelos empresariales, logrardisminuir el tiempo y costo respecto al control de acceso y permitir de esta manera quelos analistas inviertan ms esfuerzo en los procesos de negocio de la organizacin.

Para alcanzar este objetivo tuvimos en cuenta los siguientes enfoques de unaArquitectura SOA:

- Desde un punto de vista arquitectnico separamos los aspectos de seguridad delos propios de la aplicacin, con el objetivo de tener un mayor control de laejecucin de estos ltimos. Las arquitecturas orientadas a servicios Web son una

buena plataforma para realizar esta separacin, porque al estar basadas enestndares favorece a la modularizacin e integracin [12].

- Desde el punto de vista de la definicin de los procesos de negocio separamoslos aspectos relacionados con el manejo del flujo de trabajo en la organizacin

con aquellos que especifican el contexto de ejecucin de cada uno de esosprocesos, consiguiendo una mayor flexibilidad en la administracin y gestin deprocesos.

- A nivel arquitectnico incluimos un subsistema por cada conjunto de aspectosfuncionales. Como, en muchos casos, esos subsistemas tienen que interactuarcon los otros, una solucin es la implementacin de cada uno de ellos como unservicio Web. Esto hace que cada parte del sistema pueda usar las dems enforma 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 lepermitirn 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 principalescaractersticas y ventajas del modelo. Luego se presentan las reglas que elmodelo debe contemplar para una correcta implementacin. Y por ultimo senombran algunas limitaciones que dan pie a futuras mejoras.

3.

En el capitulo 4 se describe la Arquitectura Propuesta y cada uno de loscomponentes. Luego se muestra un ejemplo prctico de cmo integrar nuestraArquitectura 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 RBACen lenguaje Java [11], que sirve para gestionar una distribucin RBAC en unaorganizacin.


14/76

4 Captulo 1-Introduccin al Proyecto

5. En el Capitulo 6 se presentan las conclusiones de los resultados obtenidos y losposibles trabajos futuros destacando los aportes y limitaciones de esta tesis.

6. En el Anexo I se muestra el desarrollo de un Prototipo del modelo RBACorientado a servicios web en lenguaje java.


15/76

Captulo 2

Tecnologa Subyacente

En el siguiente captulo vamos a hacer una breve revisin de la tecnologasubyacente, para familiarizar al lector con los tpicos necesarios que le permitirncomprender mejor los objetivos planteados.

Si bien los tems descriptos en este capitulo no llegan a desplegar en detalle todo elcontenido de cada una de las tecnologas, si ayuda al lector a tener una visin suficientecomo 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 lassiguientes 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 aServicios (SOA, Software Oriented Architecture) [12] ha evolucionado a travs de losltimos aos. Este avance ha dado lugar a un estilo de arquitectura de software que tienecomo caracterstica principal promover el desacople entre los componentes de formaque se puedan reutilizar, y as permitir crear aplicaciones basada en serviciosindependientes de la plataforma, lenguaje y sistema operativo.

El elemento bsico de SOA es el servicio [12], el cual es un mdulo de software autocontenido que realiza una determinada tarea. Los servicios son componentes desoftware que no requieren que los desarrolladores usen una tecnologa subyacenteespecfica 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 losservicios para lograr la funcionalidad deseada, y por consiguiente dar lugar a quenuevos procesos de negocio se puedan construir utilizando los servicios existentes. Porejemplo, el pedido de un cliente puede estar representado por un proceso de negocio queinteracte asincrnicamente con los servicios necesarios.

En resumen, podramos listar las siguientes ventajas [12] de las Arquitecturas SOA:


16/76

6 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 aun proyecto de software actual.

2.2 XML (Extensible Markup Language)

Es un metalenguaje que especifica la sintaxis utilizada para definir otros lenguajes deetiquetas estructurados. Es una arquitectura ms abierta y extensible, pues no necesitaversiones para que puedan funcionar en distintas versiones de navegadores, adems losidentificadores pueden crearse de manera simple y ser adaptados en el acto enInternet/intranet por medio de un validador de documentos (parser) [13].

Con XML se obtiene mayor consistencia, homogeneidad y amplitud de losidentificadores descriptivos de documentos (los RDF Resource DescriptionFrameWork), con el objetivo de integrar datos e intercambiar documentos entre lasaplicaciones tanto en la propia PC como en una red local o extensa. La extensibilidad yflexibilidad 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 sonfciles de leer y razonablemente claros, esta caracterstica hace que sea muy simpleescribir programas para procesar este tipo de documentos.

2.3 Qu son los Servicios Web?

Son componentes de software cuya caracterstica principal es proporcionarmecanismos de comunicacin estndares entre diferentes aplicaciones, que interactanentre s para presentar informacin dinmica al usuario. Se los puede definir como elmedio para exponer y hacer disponible la funcionalidad de los sistemas de informacinmediante las tecnologas estndar Web, la cual reduce el efecto de la heterogeneidad delas diferentes plataformas que tienden a coexistir en los sistemas de hoy en da [5].

Definicin del World Wide Web Consortium (W3C) [14]: Una aplicacin softwareidentificada por un URI (Uniform Resource Identifier), cuyas interfaces se puedendefinir, describir y descubrir mediante documentos XML. Un servicio Web soportainteracciones directas con otros agentes software utilizando mensajes XMLintercambiados mediante protocolos basados en Internet.

Para proporcionar interoperabilidad y extensibilidad entre estas aplicaciones, y que almismo tiempo sea posible su combinacin para realizar operaciones complejas, esnecesaria una arquitectura de referencia estndar.


17/76

2.3 Qu son los Servicios Web? 7

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 informacina travs de una aplicacin cliente haciendo una peticin al servicio Web A, que ofrecesus servicios a travs de Internet. Para proporcionar al cliente la informacin quenecesita, este servicio solicita a su vez informacin a otros recursos (otros Servicios) loque lo convierte a su vez en cliente de otros Servicios Web que le van entregando lainformacin requerida.

En todo este proceso intervienen una serie de tecnologas que hacen posible estacirculacin de informacin, que describiremos en las siguientes secciones de estecaptulo.

2.3.1 XML y Los Servicios Web

Ahora que ya conocemos algo ms sobre XML nos queda responder porque XML esutilizado 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 compaastecnolgicas que integran en su software compatibilidad con dicho lenguaje.Esto quiere decir que la gran mayora del software permite la compatibilidad conXML 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 elsentido final de los Servicios Web).

Posee gran simplicidad de sintaxis, esto quiere decir que es muy fcil de escribircdigo en XML y la representacin de los datos es casi entendible por cualquierser humano. Esto lo hace muy flexible a la hora de querer representar datos decualquier especie. Basta con disponer de cualquier editor de texto y aprenderunas cuantas instrucciones bsicas para estar en condiciones de escribir cdigoXML, el cual ser soportado o entendido por cualquier aplicacin. El hecho de


18/76


que este metalenguaje sea tan fcil de codificar y de entender lo convierte en ellenguaje ideal para utilizarlo en los servicios Web.

No necesita de ningn protocolo de trasporte especial, solo de un protocolo quepueda 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 variosdispositivos; se destaca por su capacidad de transmitir informacin compleja. Los datos

pueden ser transmitidos a travs de HTTP, SMTP, o algn otro protocolo de transportea travs de un formato especifico de mensajes. Por lo tanto el objetivo de SOAP esorganizar la informacin utilizando XML de forma estructurada y tipada de forma talque 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) ybody (cuerpo).

Figura 2.2 Composicin del mensaje SOAP

En resumen podemos decir que el protocolo SOAP posee las siguientescaractersticas:

Un formato de mensaje para comunicaciones en una direccin, describiendo como seorganiza la informacin en un documento XML.

Un conjunto de normas para implementar interacciones al estilo RPC mediantemensajes SOAP, definiendo como los clientes pueden invocar un procedimiento remotoenviando un mensaje SOAP y como los servicios pueden replicar enviando otromensaje al cliente.


19/76

2.4 SOAP (Protocolo Simple de Acceso a Objetos) 9

Un conjunto de reglas que cualquier entidad que procesa un mensaje SOAP debeseguir, las cuales definen que elementos deberan leer y comprender, y las acciones quedeberan realizar en caso que el contenido sea incomprensible.

Una descripcin de cmo su mensaje SOAP se debera transportar sobre HTTP ySMTP.

2.5 WSDL (Lenguaje de Descripcin de Servicios Web)

El lenguaje de descripcin de servicios Web (WSDL, Web Service DescriptionLanguage) [13] es un dialecto basado en XML para describir un servicio Web que

proporciona la informacin necesaria al cliente para interactuar con el servicio. Esextensible y se pude utilizar para detallar, prcticamente, cualquier servicio de red,incluyendo SOAP sobre HTTP e incluso protocolos que no se basan en XML comoDCOM 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 eimportancia de describir las comunicaciones de forma estructurada. WSDL afronta estanecesidad definiendo una gramtica XML que describe los servicios de red comocolecciones de puntos finales de comunicacin capaces de intercambiar mensajes. Lasdefiniciones de servicio de WSDL proporcionan documentacin para sistemasdistribuidos y sirven como frmula para automatizar los detalles que toman parte en lacomunicacin entre aplicaciones.

En WSDL, la definicin abstracta de puntos finales y de mensajes se separa de lainstalacin concreta de red o de los enlaces del formato de datos [1]. Esto permite lareutilizacin de definiciones abstractas: mensajes, que son descripciones abstractas delos datos que se estn intercambiando y tipos de puertos, que son colecciones abstractasde operaciones. Las especificaciones concretas del protocolo y del formato de datos

para un tipo de puerto determinado constituyen un enlace reutilizable. Un puerto sedefine por la asociacin de una direccin de red y un enlace reutilizable; una coleccinde puertos define un servicio. Por esta razn, un documento WSDL utiliza los siguienteselementos en la definicin de servicios de red:

Types: contenedor de definiciones del tipo de datos que utiliza algn sistema detipos (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 depuerto 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 bloqueAbstracto o Concreto respectivamente de la estructura de un documento WSDL:


20/76


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 definircmo se dar a conocer el servicio Web para que los clientes interesados puedandescubrirlo fcilmente y utilizarlo en sus aplicaciones. En la actualidad, ya existe unmecanismo de descubrimiento que cumple estos requisitos: UDDI (UniversalDescription Discovery and Integration) [13], el cual es un registro pblico diseado paraalmacenar de forma estructurada informacin sobre empresas y los servicios que stasofrecen.

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 datosy poder encontrarlos posteriormente en funcin de la categorizacin. Lo ms importantees que UDDI contiene informacin sobre las interfaces tcnicas de los servicios de unaempresa. A travs de un conjunto de llamadas a API XML basadas en SOAP, se puedeinteractuar con UDDI tanto en tiempo de diseo como de ejecucin para descubrir datostcnicos de los servicios que permitan invocarlos y utilizarlos.


21/76

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 delDepartamento para Ciencias de la Computacin de la Universidad Nacional delComahue. 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 queconsiste en cmo aplicar el framework propuesto para lograr control de acceso basadoen roles al Laboratorio Remoto.

Un laboratorio de acceso remoto (LAR) es "un espacio de trabajo electrnico para lacolaboracin y experimentacin en investigacin u otras actividades creativas, para lageneracin y distribucin de los resultados de investigacin utilizando tecnologas deinformacin distribuidas" [3]. Este trabajo describe una infraestructura para laimplementacin de aplicaciones para el acceso remoto a laboratorios y para la gestinde 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 deinfraestructura que promuevan la disponibilidad de recursos y apoyan la escalabilidadde procesos en la tarea educativa sostenida por tecnologas de informacin.

Plantea aprovechar el avance en las tecnologas de internet y el aumento de lavelocidad de los medios de comunicacin digitales con el fin de desarrollar softwaredistribuido, y as lograr alta disponibilidad de recursos virtuales y fsicos a mayorcantidad 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 ydesarrollar arquitecturas de servicios que permitan un acceso flexible y controlado. Deesta 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 nuevosrecursos a los LAR sin modificar sus arquitecturas de servicios actuales, sinoextendiendo y adaptndose a las mejores tecnologas de comunicacin.

Para llevar a cabo la construccin de este trabajo, se dise un Framework Orientadoa Objetos (FOO) basado en Java que permite la implementacin de aplicacionesaltamente adaptables a los cambios tecnolgicos y desacopladas de las tecnologas decomunicacin utilizadas para el acceso, obteniendo herramientas reusables para elacceso 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 msorganizaciones.

En base al marco tecnolgico que ofrece este proyecto informtico, planteamos enesta tesis el diseo de un framework que logre adaptarse fcilmente a sistemasdistribuidos colaborativos sin interferir demasiado en el desarrollo y construccin de losmismos.


22/76


23/76

3.1 Caractersticas del Modelo RBAC 13

Despus de proporcionar a los administradores la contrasea de usuarioadministrador, no resultaba fcil limitar en mayor medida a estos usuarios.

En el mejor de los casos, revocar el acceso de un administrador requera lamodificacin de la contrasea comn y la notificacin a los demsadministradores. Pero siendo ms realistas, la sola modificacin de la contrasea

no resultaba ser suficiente para revocar de forma efectiva el acceso, ya que sepodran haber puesto en marcha otros mecanismos de acceso alternativos.

La responsabilidad individual era prcticamente imposible de ejercer con unacuenta de usuario administrador compartida. En consecuencia, resultaba difcilrealizar un anlisis adecuado despus de producirse un suceso de seguridad y, enalgunos casos, imposible.

Con el modelo RBAC se logr eliminar estos obstculos al ofrecer la capacidad deasignar conjuntos de tareas a cuentas de usuario ordinarias configuradasapropiadamente, y tambin conseguir mitigar la sobrecarga de administracin asociadaa 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 enfuncin de un conjunto de restricciones. El modelo de referencia de RBAC definetrminos que componen este modelo como lo son: usuarios, roles, permisos,operaciones y objetos, as como las funciones y relaciones que se incluyen en esteestndar [6].

Una solicitud de control de acceso puede considerarse como una pregunta quecombina 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 elobjeto 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 enun objeto. Un usuario puede tener concedidas diversas autorizaciones, cada una de ellascon distintos privilegios sobre los recursos.


24/76

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, esmantener 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 deautorizaciones de cada usuario puede ser totalmente distinto de los conjuntos de losdems usuarios [6].

Por desgracia, este enfoque resulta tambin difcil de administrar ya que, a medidaque se agregan usuarios, es necesario determinar exactamente qu autorizacionesrequiere cada usuario. Asimismo, cuando se realizan auditoras, es necesario examinarcada usuario individualmente para determinar las autorizaciones correspondientes.

RBAC resuelve estos problemas agrupando en roles a los usuarios con necesidadesde autorizacin comunes. Los roles sirven de mecanismo de agrupacin para simplificarla asignacin y la auditora de las autorizaciones. En lugar de asignar directamente unaautorizacin a un usuario, estas se asignan a roles predefinidos. A medida que seagregan usuarios al sistema, se les asigna un conjunto de roles, que determinan lasacciones 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 laincorporacin de nuevas versiones del modelo, extendiendo su funcionalidad y robustezcon cada una de ellas [7]. En esta seccin se describe cada una de las versiones demodelos RBAC conocidas hasta ahora. En la figura 3.1 se muestran en resumen cadauno 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 unusuario tiene diferentes roles, y cada rol lleva asociado algn permiso. Posee lossiguientes componentes centrales del modelo:

Conjuntos: USUARIOS (U) ROLES (R) PERMISOS (P) OPERACIONES (OPS) OBJETOS (OBJ)


25/76

3.4 Modelos RBAC y su evolucin 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: SU (A cada sesin del conjunto de Sesiones (S) lecorresponde solo un usuario del conjunto de Usuarios (U))

sesion_roles: S 2R (A cada sesin del conjunto de Sesiones (S) lecorresponde un subconjunto del conjunto de Roles (R))

Figura 3.2 Modelo RBAC0

En la figura 3.2 podemos observar los conjuntos USUARIOS, ROLES yPERMISOS, 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 dejerarqua de roles [7].Esta propiedad bsicamente consiste en la capacidad que tiene un rol en heredar lasautorizaciones 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 losprivilegios del rol anterior. Por ejemplo, el usuario con mayor jerarqua dentro de unaorganizacin puede tener acceso a cualquier tipo de informacin, incluso a lainformacin 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 unadefinicin de este concepto.


26/76


En la figura 3.3 se puede ver el agregado de la relacin jerarqua de roles al modeloanterior.


- Se agrega un orden parcial llamado jerarqua de roles, RH R x R(el conjuntoJerarqua 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' r. (usuario_sesion(s),r')

UA}

(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 incluidoen la relacin UA)

- Un usuario puede establecer una sesin con cualquier combinacin de los rolesque sean menores a los que l tiene asignado.

- Similarmente, los permisos de una sesin son aquellos asignados directamente alos 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 lasiguiente seccin. El uso ms frecuente que se tiene con las restricciones es laseparacin de tareas dentro de una organizacin. Estas restricciones, conocidas con elnombre de Cardinalidad, Separacin esttica de tareas (SSD) y Separacin Dinmica deTareas (DSD), sirven para prevenir fraudes restringiendo la combinacin de privilegios


27/76

3.4 Modelos RBAC y su evolucin 17

disponibles para los usuarios. En la figura 3.4 se muestra el agregado de estasrestricciones al modelo RBAC0.


3.4.4 RBAC3

Este es el modelo ms complejo de los que se han presentado con anterioridad, yaque incluye tanto las jerarquas de roles como las restricciones. En RBAC3 [7], lasrestricciones pueden ser impuestas sobre los roles jerrquicos dentro de unaorganizacin.

La figura 3.5 ilustra la combinacin de RBAC1 y RBAC2para componerRBAC3


3.5 Reglas del Sistema RBACEn esta seccin nos enfocamos en representar el marco conceptual de RBAC

basndonos en reglas que definen el alcance del modelo y sus restricciones [4]. Estasreglas fueron tenidas en cuentas durante el diseo y desarrollo del Framework propuesto

para esta tesis.


28/76


Regla 1 (Jerarqua de Roles)Si un usuario est autorizado para acceder a un rol yel rol contiene otro rol, entonces el usuario tambin est autorizado para acceder al rolcontenido [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 ydifcil de administrar. Para simplificar esta situacin, el modelo ofrece la posibilidad dedefinir el conjunto de roles en la organizacin, de manera tal que se pueda identificaraquellas operaciones superpuestas entre cada uno de ellos, y tambin aquellasoperaciones 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 especializacionesen los controles de acceso y facilitar la modelizacin de la seguridad en sistemas mscomplejos.

El sistema RBAC diseado para esta tesis permite administrar y configurar los rolesde tal forma que se pueda especificar claramente la jerarqua de roles de manera naturaly cumplir sin problemas con esta regla.

Regla 2 (Separacin Esttica de Tareas) Un usuario estar autorizado comomiembro de un rol solo si ese rol no es mutuamente exclusivo con cualquiera de losotros roles de los cuales el usuario ya es miembro [4].

Dos roles son mutuamente exclusivos cuando un mismo usuario no puede sermiembro de ambos roles, pues las operaciones de dichos roles generan conflicto deintereses. Para asegurar esta propiedad el sistema RBAC debe proveer de unaherramienta para llevar a cabo una poltica de Separacin Esttica de Tareas, y asvalidar 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 unmiembro adicional [4].

Se debe permitir especificar la capacidad de un Rol, y asegurar que sta no seasobrepasada en la asignacin de usuarios a dicho rol. Un usuario puede convertirse enun nuevo miembro de un rol siempre y cuando el nmero de miembros permitidos parael rol no sea excedido.

Con esta restriccin se pueden controlar aun ms los miembros de un rol. Porejemplo, se pueden limitar las asignaciones al rol administrador, asegurando que nohaya 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, yas luego permitir ejecutar alguna operacin de dicho rol.


29/76

3.5 Reglas del Sistema RBAC 19

Regla 5 (Ejecucin de Roles)Un usuario puede ejecutar una operacin, solo si elusuario est actuando dentro de un rol activo.

A medida que el usuario solicita acceso a distintos recursos del sistema, RBAC vaactivando sobre la sesin aquellos roles que poseen la autorizacin correspondiente pararealizar 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 unnuevo 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 elmomento de vincular un usuario a algn rol, la Separacin Dinmica de Tareas aplicarestricciones a las activaciones simultaneas de roles, o sea que se emplea en tiempo deejecucin. 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 encomprobar que un usuario solo puede ejecutar operaciones que son autorizadas por unrol activo en la sesin. Esto quiere decir que el rol debe pertenecer a la lista de rolesactivos del usuario o ARS (Active Rol Set).

El sistema debe llevar dinmicamente una estructura de datos que implemente elARS correspondiente a la sesin de un usuario, y dejarla disponible para poder cotejaresta regla.

Regla 8 (Separacin Operacional de Tareas) Un rol puede estar asociado con unaoperacin 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 aplicageneralmente para evitar fraudes. Pues se basa en la idea de que si existen varias tareasrelacionadas dentro de una mismo rol, se presenta la posibilidad de que un mismousuario 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 decompra 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 defraude puede ser disminuida. El sistema debe otorgar facilidades a la hora de configurar


30/76


los roles y as evitar que un usuario pueda ejecutar una serie de operacionesencadenadas pudiendo llegar a un posible fraude.

Regla 9 (Autorizacin de Acceso a Operaciones) Un sujeto puede acceder a unobjeto solo si el rol es parte del conjunto de roles actualmente activo del sujeto, el rolest 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 Operacionesdefinida arriba asegura que el acceso de un sujeto a un objeto RBAC solo puede serobtenido a travs de operaciones autorizadas para los roles activos autorizados.

En definitiva, la Autorizacin de Acceso a Operaciones, indica que el control de losaccesos de los sujetos a los objetos RBAC asegura las polticas de la organizacin a losrecursos.

3.6 Limitaciones del modeloEl modelo RBAC se caracteriza por las grandes ventajas mencionadas anteriormente,

pero sin embargo consideramos que presenta una serie de carencias [8] para el controlde acceso en procesos de naturaleza colaborativa, que vale la pena resaltar para futurasmejoras:

En RBAC la naturaleza de los roles puede ser denominada esttica, ya que carecende 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 unusuario, pero no tiene en consideracin las sesiones establecidas por otros usuarios en elsistema, 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 enciertos roles y sobre instancias de objetos individuales. Un ejemplo a esta situacinpodra ser en el laboratorio remoto, donde puede ser necesario crear un grupo de trabajode estudiantes, con el rol Alumnos de primer ao, que tengan acceso temporal a unrecurso en particular. RBAC no puede controlar que otros estudiantes del mismo rol queno 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 permisoscomunes a grupos de usuario. Esto es conseguido en el modelo RBAC creando un rolespecfico y asignando de forma individual este rol a cada usuario

3.7 Conclusiones sobre el modelo RBACConsideramos 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 laslimitaciones anteriormente mencionadas, creemos que posee caractersticas relevantes


31/76


32/76


33/76

Captulo 4

Presentacin de la Arquitectura PropuestaEn este captulo describimos el ncleo de nuestra tesis, una arquitectura RBAC

basada en servicios Web, que sirva de Framework a los diseadores y desarrolladores desoftware, para que puedan integrar fcilmente el control de acceso a sus diseos ymodelos empresariales. Explicaremos el comportamiento de cada uno de loscomponentes de la Arquitectura, sus propiedades observables, y las relaciones existentesentre ellos. Esta comprensin es indispensable para entender cmo aplicar esteFramework 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 yla descripcin de cada uno de sus componentes. Para finalizar con el capitulo se muestraun ejemplo prctico de cmo llevar a cabo la integracin de este Framework a un

proyecto de software.

4.1 Porqu elegimos una Arquitectura Orientada aServicios 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 deInformacin (IT) con las necesidades de negocio, logrando un dinamismo en la toma de

decisiones, con informacin ms exacta y actualizada. Asimismo con la posibilidad deobtener mejor informacin en un tiempo menor, habilita a las organizaciones areaccionar de manera ms gil y rpida cuando surgen problemas o cambios.

La tecnologa SOA permite una abstraccin en las implementaciones de los serviciospromoviendo que los desarrolladores se dediquen de lleno a los procesos importantesdel negocio, y as desarrollar aplicaciones de manera ms rpida y econmica. El diseode servicios basado en estndares facilita la creacin de un repositorio de serviciosreutilizables que se pueden combinar en servicios de mayor nivel y aplicacionescompuestas en respuesta a nuevas necesidades de la empresa. Con ello se reduce elcosto del desarrollo de soluciones y de los ciclos de prueba, se eliminan redundancias yse consigue su puesta en produccin en menor tiempo.

En sntesis, el uso de un entorno y modelo de desarrollo unificado simplifica yhomogeneiza la creacin de aplicaciones, desde su diseo y prueba hasta su puesta enmarcha y mantenimiento.

Finalizando, otra ventaja importante de las soluciones orientadas a servicios es que proporcionan una infraestructura comn (y una documentacin comn tambin) paradesarrollar servicios seguros, predecibles y gestionables. Conforme van evolucionandolas necesidades de negocio, SOA facilita la posibilidad de aadir nuevos servicios yfuncionalidades para gestionar los procesos crticos. Se accede a los servicios y no a las


34/76


35/76

4.1 Porqu elegimos una Arquitectura Orientada a Servicios para el diseo de nuestroFramework 23

aplicaciones, y gracias a ello se optimizan las inversiones realizadas en IT potenciandola posibilidad de introducir nuevas capacidades y mejoras. Adems, puesto que seutilizan 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 interfierenentre ellos, la estrategia de SOA permite dotarse de un nivel de seguridad superior.

4.2Arquitectura RBAC Orientada a Servicios

En esta Seccin presentamos los elementos que forman parte del diseo de nuestrotrabajo, sus relaciones, responsabilidades y colaboraciones. Desde esta perspectivanuestra Arquitectura est dividida en las siguientes tres capas:

- Capa de Aplicacin: en esta capa se encuentra la aplicacin cliente que poseelos elementos y servicios propios del negocio, e interacta con la capa deServicios de Control de Acceso para evaluar el acceso a los recursos de laaplicacin, cuando un sujeto as lo requiera.

-

Capa de Servicios de Control de Acceso: Esta capa posee todos loscomponentes que se encargan de gestionar el control de acceso. Contiene lasecuencia de operaciones a llevar a cabo y las polticas de seguridad a tener encuenta en el momento de otorgar acceso a los recursos de la aplicacin.Interacta con la Capa de Infraestructura RBAC para obtener informacinrespecto a Roles, usuarios y autorizaciones.

- Capa de Infraestructura RBAC: En esta capa se encuentra la base de datosRBAC. En ella se alojan los roles, usuarios y autorizaciones. Esta base de datos

posee un mdulo de configuracin donde se personaliza el sistema RBACacorde 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 lainteraccin entre ellos, y sus interfases.


36/76


37/76


38/76

26 Captulo 4- Presentacin de la Arquitectura Propuesta

Figura 4.2 Diagrama de Componentes y distribucin

En el diagrama podemos observar que existe una alta interaccin entre los ServiciosWeb 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 enuno? La respuesta se basa en aprovechar las ventajas de una arquitectura SOA [15] paralograr 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 mismotiempo una integracin eficiente de los componentes de la arquitectura a un proyecto desoftware.

Por ejemplo, uno de los propsitos de separar los componentes Servicio WebEjecutor y Servicio Web Conmutador es disponer de ms de una implementacin deeste ltimo componente, y de esta manera poder independizar la secuencia deoperaciones a ejecutar segn las diferentes polticas de acceso que una organizacin

puede disponer en distintos momentos. La modularizacin aplicada al diseo de laarquitectura propuesta en esta tesis logra esta separacin entre ambos componentes

permitiendo adaptar fcilmente cambios en las polticas de la organizacin sinnecesidad de manipular al Servicio Web Ejecutor que est directamente relacionado conla aplicacin empresarial.

Adems el Servicio Web Ejecutor, provee a los desarrolladores una interface simplepara ser usada a la hora de validar un acceso a una aplicacin, por lo que no es necesarioque el analista deba conocer como el componente Servicio Web Conmutador cooperacon el Servicio web RBAC para resolver las distintas problemticas a la hora de validarel acceso a un recurso. De esta manera el Servicio Web RBAC es el nico responsablede acceder a las base de datos y recuperar informacin relativa a usuarios, roles yautorizaciones, y responder a otros componentes cuando requieran este tipo de datos.Este desacoplamiento logra evitar que otras partes tengan que acceder a las base dedatos RBAC explcitamente encapsulando los mtodos y conexiones al repositorio de


39/76

4.2 Arquitectura RBAC Orientada a Servicios 27

datos en este componente alcanzando as un mayor nivel de seguridad de lainformacin.

Por ltimo podemos destacar que con esta distribucin de los componentes seconsigue una mayor flexibilidad en las tareas de desarrollo, pues como se mencionanteriormente, una arquitectura orientada a servicios permite reutilizar los mdulosexistentes para generar nuevas aplicaciones. Como consecuencia tambin se reducen loscostos de mantenimiento.

4.2.3 Interaccin entre los componentes de la Arquitectura RBAC

Para expandir el campo de visin de nuestro Framework, mostramos mediantediagramas de secuencia como los objetos que componen la arquitectura interactanentre si mientras transcurre el tiempo.

En la Figura 4.3, presentamos un primer diagrama de secuencias que resume lamecnica de interaccin entre los servicios para generar primero una sesin, y

posteriormente resolver el acceso a algn recurso del sistema, es decir la secuencialgica 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 utiliceno necesita tener conocimiento de las colaboraciones internas entre los servicios de laCapa de Servicios de Control de Acceso, por ser estas transparentes a l, las instanciasde los servicios Conmutador y RBAC no forman parte de este primer diagrama. Comoejemplo de estas colaboraciones internas podemos citar los posibles conflictos deintereses que puedan ocurrir durante una sesin.

Figura 4.3 Diagrama de secuencias de interaccin entre componentes


40/76


Continuando con nuestro escenario, describimos la secuencia de mensajes, que vande un objeto a otro, a travs del tiempo:

1- El Sujeto intenta iniciar sesin en el sistema, ingresando un usuario ycontrasea, considerando que este usuario final del sistema fue

primero dado de alta en RBAC y asignado a un rol vlido.2- El Sistema debe llamar al servicio Web RBAC para validar a este

usuario en RBAC.

3- El Servicio Web RBAC ejecuta tres procesos. Primero valida el parusuario contrasea, luego busca el rol de este usuario. En caso queest todo bien, el mdulo crea una sesin RBAC.

4- El Servicio Web RBAC devuelve un mensaje de acceso otorgado.5- El Sistema crea su propia sesin para este usuario.6- El Servicio devuelve un mensaje de acceso otorgado al Sujeto.7-

El Sujeto intenta acceder a un recurso del sistema.8- El Sistema llama al Servicio Web Ejecutor para validar el acceso

9- Ejecutor verifica el acceso. Tanto el Servicio Web RBAC como elServicio Web Conmutador colaboran con Ejecutor para resolver este

punto en forma transparente para el Sujeto.

10- Ejecutor devuelve un mensaje de acceso otorgado al sistema.11- El Sistema habilita el acceso al Sujeto sobre el recurso en cuestin.

En el diagrama de secuencia de la figura 4.4 ampliamos el escenario anterior paramostrar 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 serelacionan estos componentes, teniendo en cuenta no solo la perspectiva del ingenierode software que hace uso de este framework, sino tambin en la cadena decolaboraciones que existen entre ellos para llevar a cabo el control de acceso a unrecurso.


41/76


Figura 4.4 Diagrama de secuencias de interaccin entre componentes

1- El Sujeto intenta acceder a un recurso del sistema.2- El Sistema invoca al mtodo puedeEjecutar del Servicio Web Ejecutor

para validar el acceso, pasando por parmetros el usuario, clave, rol,recurso y operacin.

3- As mismo, el Servicio Web Ejecutor llama al mtodo verificarAccesodel Servicio Web conmutador, pasando por parmetro el usuario,clave, rol, recurso y operacin.

4- El Servicio Web Conmutador lanza una secuencia de operaciones, para validar el acceso. La primera de ellas es llamar al mtododevolverRoles del Servicio Web RBAC para obtener as una lista deroles correspondientes a la jerarqua de roles del usuario. En estaocasin se pasa por parmetros el usuario y clave.

5- El servicio Web RBAC llama as mismo la operacinBuscarRolesJerarqua, accediendo a la base de datos RBAC paraobtener dicha informacin.

6- El Servicio Web RBAC devuelve al Conmutador la lista de rolesrequerida.

7- El servicio Web Conmutador llama ahora al mtodo tieneOperacionpor cada uno de los roles de la lista obtenida anteriormente, pasando por parmetro un rol, recurso y operacin. Esto se repite hastaverificar si alguno de los roles tiene la autorizacin requerida por elusuario.

8- Por cada invocacin del paso anterior, el Servicio Web RBAC llama ala operacin verificarAutorizacion, que accede a la base de datosRBAC para consultar si el rol pasado por parmetro puede ejecutar laoperacin correspondiente sobre el recurso, ambos datos tambin

pasados por parmetro.


42/76


9- El Servicio Web Conmutador recibe como respuesta que existe laautorizacin requerida.

10- Como ltimo paso de esta secuencia de operaciones, Conmutadorinvoca la operacin separacionDinTareas para cerciorarse, antes deactivar el rol correspondiente, que no exista algn posible conflicto deintereses con otros roles activos del usuario. En esta ocasin pasa por

parmetros el rol y el usuario.

11- Servicio Web RBAC llama a s mismo la operacinverificarSeparacionDin con rol y usuario como parmetros. Accede alas base de datos RBAC y verifica en la Lista de Roles Activos delusuario (ARS) que no exista exclusividad mutua entre este rol y los yaactivos en la sesin. Luego procede a activar el rol pasado por

parmetro.

12- El Servicio web Conmutador recibe una notificacin que no existenconflicto de intereses.

13- El Servicio Web Ejecutor recibe un aviso de acceso otorgado.14- Ejecutor devuelve un mensaje de acceso otorgado al sistema.15- El Sistema habilita el acceso al Sujeto sobre el recurso en cuestin.

En el Anexo A est disponible una implementacin de nuestra Arquitecturadesarrollada en Java 6 [11], donde se detalla cada uno de los componentes yoperaciones. 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 ejemploprctico 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 esfuerzoinvertido 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. Porlo 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 alestar basada en servicios Web, no tendr que preocuparse de cmo estos componentesestn 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 integrarnuestra Arquitectura RBAC Orientada a Servicios a un proyecto denominadoLaboratorio Remoto, usando como ambiente integrado de desarrollo (IDE, IntegratedDevelopment 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 deControl de Acceso: el servicio RBAC y el servicio Ejecutor. El primero ser invocadoen el momento de crear una sesin dentro del sistema o aplicacin que se est


43/76


desarrollando. El segundo en cambio, ser llamado cada vez que sea necesario evaluarel acceso a algn recurso del sistema.

La primera actividad de la Integracin, es crear las referencias a los servicios WebRBAC y Ejecutor que actuarn de Proxy en el Proyecto Netbeans [10]. Estas referenciasson llamadas clientes de servicios Web (Web service Client) y sirven comorepresentante del servicio remoto para poder consumir las operaciones que este ofrece.Estos clientes luego de creados, pueden ser testeados para conocer que las operacionesson consumidas con xito. En la figura 4.5 se muestra como realizar la creacin de estosClientes 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, seinvoca a la operacin buscarRol de la referencia RbacService. En la Figura 4.7 semuestran las posibles operaciones que RbacService ofrece.


44/76


Figura 4.7 Operaciones del Servicio Web RBAC

Una vez seleccionada la operacin buscarRol, Netbeans [10] generar el siguientecdigo:

Podemos ver que el IDE ha creado un objeto port que a partir de ahora servir deProxy 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 ingresode usuarios a la aplicacin. Como un ejemplo particular, se llama a la operacinbuscarRolde la siguiente forma:

De una manera muy simple se ha logrado implementar la validacin del ingreso deun usuario a la aplicacin Laboratorio Remoto. Tambin, de forma transparente, se hacreado una sesin RBAC ligada al usuario, que permanecer activa mientras dure lasesin del mismo en la aplicacin, y servir como soporte en los distintos controles deacceso.

Como tercera actividad, se debe evaluar el acceso a los recursos del sistema haciendouso del servicio Web Ejecutor. Considerando que se ha creado y testeado el clienteWeb, se est en condiciones de invocar a la operacinpuedeEjecutarde Ejecutor, paraotorgar o denegar el acceso.

Ser una tarea del desarrollador, decidir donde es ms conveniente realizar lainvocacin, dependiendo tambin del lenguaje que est utilizando o las facilidades quele puedan llegar a ofrecer el IDE de desarrollo.


45/76


Una posible estrategia es evaluar el acceso a un recurso en el momento de sucreacin. En Netbeans [10] por ejemplo, se puede hacer uso del evento Pre creationcode para invocar a puedeEjecutar, dndole acceso al usuario solo a aquellos objetos

permitidos en su perfil. Esta estrategia de implementacin se usa por ejemplo, paramostrar 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 unrecurso en tiempo de ejecucin. Para esta situacin el acceso debe ser evaluado almomento de aplicar alguna accin sobre el objeto, por ejemplo, cuando se le hace unclic con el Mouse o se quiere dar de algn modo referencia sobre l.

En definitiva, nuestra arquitectura no pone restricciones sobre el uso de lasoperaciones de los servicios que esta posee, el desarrollador es libre de aplicar lasmejores prcticas de programacin para resolver el control de acceso en su proyecto dela manera ms eficiente posible.

Continuando con la tercera actividad, resolver el acceso a un recurso, se debe crear elProxy como un objeto global al sistema, para hacer uso de este cuando se invoque aalguna operacin de Ejecutor. En primer lugar, se crea el Proxy de Ejecutor denominado

portEjecutorcomo instancia global del cliente Web creado anteriormente.

En Segundo lugar, se crea una instancia del servicio Ejecutor y se usa aportEjecutor,como referente de este servicio.

El objeto portEjecutor ahora podr ser usado todas las veces que sea necesariaaplicar alguna operacin del servicio Web Ejecutor, en especial puedeEjecutar paraverificar 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.


46/76

Capitulo 5

Mdulo de Configuracin RBACEl Mdulo de Configuracin RBAC es una parte importante del Framework

propuesto en esta tesis. Est disponible para los administradores que quieran configurarla distribucin de roles, usuarios y autorizaciones, otorgando la posibilidad de poderdefinir jerarqua de roles, adems de restricciones de acceso como los son laexclusividad 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 adaptadofcilmente 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 laseccin 3.5 del captulo 3, con el fin de garantizar una correcta configuracin deusuario, roles, autorizaciones y relaciones entre estas entidades.

5.1 Configuracin RBACEn 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 deacceso.

5.1.1 Planificacin de la distribucin de RBAC

Consideramos importante tener en cuenta los siguientes pasos antes de comenzar acrear 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 constituyeel primer paso fundamental en la distribucin de RBAC. En algunas organizaciones yaexiste este conjunto de roles, que se puede volver a utilizar al configurar el control deacceso. Lo ms habitual es que sea necesario disear los roles segn las tareas existentesasociadas a los usuarios de una organizacin.

A travs de diferentes tcnicas como encuestas, casos de uso, anlisis de las tareasdel personal de la organizacin, comprender bien el funcionamiento de la organizacin,conocer el tipo de sistemas que se utilizan en cada sector, preguntarse quienes puedenhacer qu cosas y quines deben hacer qu cosas; se puede determinar con mayor


47/76

5.1 Configuracin RBAC 35

precisin las tareas que se deben realizar en cada sector de la misma y as logrardistinguir 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, entoncesno ser posible beneficiarse de toda la administracin simplificada relativa aluso de roles.

Los roles deben corresponder con las funciones organizacionales reales de losusuarios.

Los usuarios pueden tener varias funciones y, por lo tanto, hay que disearalgunos roles simplemente con vistas a agrupar las autorizaciones comunes avarias funciones empresariales. Con este enfoque, se pueden disear los roles

jerrquicamente a fin de incluir distintas funciones mediante la inclusin de lasautorizaciones correspondientes.

5.1.1.2 Planificacin de las autorizaciones para los roles

Una vez definidos los roles de la organizacin, podemos proceder a planificar lasautorizaciones asociadas a cada uno de ellos. Si las funciones de los roles coinciden conla jerarqua de autorizaciones ya existente, la asignacin de las autorizaciones seconvierte en una tarea sencilla. Pero, si la jerarqua de autorizaciones existente nocoincide con los roles, la definicin de las autorizaciones asociadas a cada rol es unatarea ms compleja.

Consideramos los siguientes pasos a modo de ayuda [6]:

1. Obtener una lista de los servicios del sistema que se utilizan habitualmente encada 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 muestrael 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 observarel diseo de las entidades relevantes para el sistema RBAC as como sus interrelacionesy propiedades.


48/76

36 Capitulo

Figura 5.1 Diagrama Entidad Relacin para el modelado de base de datos RBAC


49/76

5.3 Empleando el Modulo de Configuracin RBAC 37

5.3 Empleando el Modulo de Configuracin RBACPara 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 sepueden efectuar.

5.3.1 Configuracin de Roles, Usuarios y AutorizacionesEl objetivo principal de la creacin del mdulo de configuracin RBAC es

proporcionar una herramienta simple para que asista al administrador en la distribucinde un modelo RBAC grado 3 (cuyas caractersticas hemos analizado en el captulo 3seccin 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 lassiguientes 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 ConfiguracinRBAC, dentro de la seccin Administrar Roles, tenemos las siguientes opciones demen:

- 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 3seccin 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 puedacrear ms de un usuario para el rol Administrador. As de esta manera configurando esterol con una cardinalidad igual a 1 estaramos garantizando esta restriccin.


50/76

38 Capitulo 5-Mdulo de Configuracin RBAC

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 estningn usuario vinculado a dicho rol y que ningn otro rol dependa de este en laJerarqua de Roles. En la figura 5.3 se muestra de manera sencilla como podemoseliminar un rol de nuestro esquema de roles, con solo seleccionarlo y presionarEliminar.

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, debemosidentificar aquellas operaciones superpuestas entre cada uno de ellos, y tambin aquellasoperaciones 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 especializacionesen los controles de acceso y facilitar la modelizacin de la seguridad en sistemas mscomplejos.


51/76


Nuestro mdulo de configuracin RBAC permite configurar fcilmente una Jerarquade Roles de manera natural, indicando el rol padre y la relacin con uno o ms roleshijos, como muestra la figura 5.4:

Figura 5.4 Formulario para Configurar la Jerarqua de Roles

Esta especializacin y generalizacin se cumple dinmicamente mediante unafuncin recursiva que se encuentra implementada en el servicio web RBAC (en elAnexo I est disponible una implementacin de esta funcin). La idea es que dichaoperacin recorra el rbol jerrquico de roles, estableciendo como nodo de partida el rolque fue asignado al usuario, e ir verificando a partir de este, y en todos los nodosdescendientes, 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, elsistema verificar si en algn rol descendiente la posee. Esta funcin es totalmentetransparente tanto para el usuario final como tambin para el programador que hace usodel Framework.

5.3.2.4 Separacin esttica y dinmica de responsabilidades y tareas

Para finalizar con la configuracin de roles de nuestro mdulo de configuracinRBAC, solo nos queda por indicar como generar las relaciones mutuamente exclusivasestticas y dinmicas que hay entre ellos. Estas restricciones tienen como finalidadhacer 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 roleslos 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 usuariovinculado al rol Alumno1 no puede ser vinculado dinmicamente al rol Alumno2. De locontrario, 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; paraeso el rol Alumno1 debe ser descendiente del rol Alumno2.


52/76

40 Capitulo 5-Mdulo de Configuracin RBAC

Esta restriccin se cumple mientras la sesin se encuentre activa durante el tiempode ejecucin de la misma, y es soportada por la lista de roles activos que est ligada a lasesin de un sujeto, cuya funcin es registrar los roles que va activando el usuario entiempo 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 potencialesconflictos 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 rolADMIN no se le puede otorgar luego el rol Alumno1. Esta es una restriccin que setiene en cuenta en el momento de asignacin de roles, y la cual se va a cumplir en todomomento durante la sesin de un usuario.

Una vez definido los roles vlidos y las relaciones entre ellos, procedemos aasignarlos a uno o varios usuarios como veremos mas adelante. Primero indicamoscomo crear los usuarios.


53/76


5.3.3 Configuracin de los Usuarios

La gestin de usuarios

tesis matias salcedo

Documents