Modelo de Control de Acceso en un Sistema Colaborativo

Modelo de Control de Acceso en un Sistema
Colaborativo
M. Sánchez 1, B. Jiménez1, F. L. Gutiérrez1, P. Paderewski1, J. L. Isla2
1
Departamento de Lenguajes y Sistemas Informáticos – Universidad de Granada.
2
Departamento de Lenguajes y Sistemas Informáticos – Universidad de Cádiz
1
{miguesr,beajv, fgutierr, patricia}@ugr.es, [email protected]
Abstract. Una de las características más importantes de los sistemas
empresariales actuales es la existencia de procesos colaborativos en los que
diferentes usuarios/subsistemas se comunican y cooperan entre si para realizar
actividades relacionadas. En estos procesos, se usan a menudo recursos
compartidos y aparecen relaciones y dependencias complejas entre las
actividades y los usuarios que las realizan, por lo que se hace necesario la
definición y administración de diferentes niveles de seguridad sobre las tareas,
los usuarios y los recursos. Dentro de los diferentes procesos de seguridad, nos
vamos a centrar en la dimensión relativa al control de acceso. Vamos a partir de
un modelo conceptual de organización que refleje los elementos necesarios para
representar la autorización y los aspectos de control de acceso en sistemas
colaborativos tomando como base el modelo RBAC. Este modelo de
organización lo vamos a integrar en una arquitectura orientada a servicios
(SOA) con objeto de facilitar el desarrollo de este tipo de sistemas. De forma
complementaria analizaremos las dimensiones de manejo de tareas y de sesión
integrándolas en la arquitectura propuesta.
Keywords: Sistemas colaborativos, modelo RBAC, modelado de grupos.
1 Introducción
Los sistemas colaborativos permiten a los grupos de usuarios comunicarse,
coordinarse y cooperar para llevar a cabo actividades comunes. Dentro de este tipo de
sistemas existe un amplio rango de aplicaciones: para compartir/editar documentos
colaborativos, para aprendizaje electrónico o para gestionar sistemas de manejo de
flujos de trabajo.
Este tipo de aplicaciones son cada vez más usadas en los sistemas empresariales
Actualmente, las empresas implantan sus servicios usando los recursos que les
proporcionan las nuevas tecnologías y más concretamente la Web. Es normal
encontrar empresas que mejoran o modifican sus procesos de negocio cuando
incorporan estas tecnologías.
Cuando las aplicaciones son trasladadas a la Web, es necesario prestar especial
atención a los aspectos relacionados con la seguridad. Aunque normalmente sólo se
226 – Sánchez, M., Jiménez, B., Gutiérrez, F.L, Paderewski, P., Isla, J.L.
presta atención a la seguridad a nivel de la transmisión de la información entre
servidores, existen otros aspectos que deben ser tenidos en cuenta, como son la
autenticación de usuarios, el control de las actividades que realizan o los permisos de
acceso a recursos compartidos.
La estructura organizativa y las políticas de control de acceso a recursos y
actividades son dos de los elementos más dinámicos en una compañía, y es necesario
ser capaz de definir una modelo de organización lo suficientemente flexible como
para poder adaptarse a los cambios.
Durante el desarrollo de un sistema los costes relacionados con los cambios en los
requisitos o la aparición de nuevos requisitos son una parte considerable del coste
total del desarrollo. Los elementos relacionados con la seguridad se dejan en muchos
casos para etapas finales del desarrollo provocando fuertes incrementos en el coste del
desarrollo final. Los temas de seguridad son tan importantes y complejos como para
necesitar ser abordados desde los primeros pasos del desarrollo y con modelos que
faciliten su adaptación y dinamismo. En nuestra opinión, es importante la integración
de los elementos de seguridad con el resto de los modelos que usamos para describir
las funcionalidades del sistema pero sin interferir demasiado.
En este trabajo mostramos la integración de un modelo de control de acceso,
complementado con la integración de un modelo para el manejo de tareas y un
modelo de sesión, en una arquitectura orientada a servicios con objeto de desarrollar
aplicaciones para organizaciones complejas con actividades colaborativas. Nuestro
modelo se ha definido con el principal objetivo de facilitar la expresión de aspectos
dinámicos en los ambientes colaborativos
En la sección 2 analizamos los elementos necesarios para obtener un control de
acceso eficiente tomando como referente un modelo basado en roles. En la sección 3
proponemos una arquitectura basada en servicios para la integración del modelo de
control de acceso especificado en la sección anterior junto a dos modelos más, para el
modelado de los elementos de sesión y el modelado de la secuencialización de tareas
dentro de un proceso de negocio. Finalmente en la sección 4 mostramos el modelo
conceptual que da soporte a la arquitectura propuesta.
2 Modelo de Control de Acceso
El control de acceso es un elemento clave en la seguridad de un sistema y sirve como
complemento importante a la definición de la interacción entre los usuarios del
sistema y en el caso de sistemas colaborativos a la interacción y coordinación entre
los diferentes usuarios y los recursos que utilizan. Los primeros trabajos relacionados
con el modelado de control de acceso en sistemas colaborativos comenzaron con Shen
y Dewan [1] y usándolos como base, se han aplicado a diferentes modelos [2]
intentando adaptarlos a las características propias de este tipo de sistemas.
A continuación se presentan los requisitos que deben cumplir los modelos de
control de acceso para sistemas colaborativos [2] [3]:
• El modelo de control de acceso debe ser fácil de usar y transparente para los
usuarios finales.
Modelo de Control de Acceso en un Sistema Colaborativo – 227
• Los efectos que provoca el control de acceso sobre el resto del sistema deben ser
claros y fáciles de comprender.
• El modelo debe permitir una gran expresividad en la especificación de las políticas
de acceso teniendo en cuenta una amplia información (roles, tareas ejecutándose,
momento en el cual se solicita el acceso, etc.). Es decir, el modelo deberá permitir
especificar políticas de acceso complejas y a un nivel de detalle alto.
• El modelo debe ser dinámico, es decir, permitir la especificación, delegación,
revocación y administración de las políticas de acceso en tiempo de ejecución
(Meta Access Control).
• Permitir proteger a distintos niveles de granularidad cualquier tipo de información
y de recursos. Es decir, deben tener la habilidad de proveer una fuerte protección
para entornos y objetos compartidos de varios tipos así como permitir un control de
acceso de grano fino para objetos y sus atributos.
• Un elemento importante en los sistemas colaborativos es el contexto, los modelos
de control de acceso deben tener en consideración este elemento para establecer los
permisos de acceso, es decir, el modelo autorizara o no el acceso teniendo en
cuenta el contexto actual en el que se encuentre el usuario.
La mayor parte de los modelos usados actualmente, se han diseñado, específicamente,
para analizar y modelar los aspectos de seguridad por lo que es necesario modelar los
aspectos funcionales de forma separada e integrarlos posteriormente. Uno de los
modelos mas usados es RBAC (Role-Based Access Control) por Shandu et al [4] [5].
Este modelo emerge rápidamente en 1990 como tecnología para asegurar y mantener
la seguridad en sistemas a gran-escala en grandes compañías. El modelo usa el
concepto de rol en vez de la asignación de privilegios directamente a usuarios. Esto
facilita la clasificación de privilegios y permite un control de acceso fino a los
recursos.
Fig 1.Elementos básicos del modelo RBAC.
228 – Sánchez, M., Jiménez, B., Gutiérrez, F.L, Paderewski, P., Isla, J.L.
RBAC está basado en la definición de un conjunto de elementos y de relaciones
entre ellos (figura 1). A nivel general describe un grupo de usuarios que pueden estar
actuando bajo un conjunto de roles y realizando operaciones en las que utilizan un
conjunto de objetos como recursos.
Entre estos cuatro elementos se establecen relaciones del tipo:
• Relaciones entre usuario y roles modelando los diferentes roles que puede adoptar
un usuario.
• Conjunto de operaciones que se pueden realizar sobre cada uno de los objetos. A
los elementos de esta relación se les denomina permisos.
• Relaciones entre los permisos y los roles. Modelamos cuándo un usuario por estar
en un rol determinado tiene permiso para realizar una operación sobre un objeto.
El modelo RBAC incluye un conjunto de sesiones donde cada sesión es la relación
entre un usuario y un subconjunto de roles que son activados en el momento de
establecer dicha sesión. Cada sesión esta asociada con un único usuario y cada
usuario tiene una o mas sesiones. Los permisos disponibles para un usuario son el
conjunto de permisos asignados a los roles que están activados en todas las sesiones
del usuario, sin tener en cuenta las sesiones establecidas por otros usuarios en el
sistema.
RBAC añade la posibilidad de modelar una jerarquía de roles de forma que se
puedan realizar generalizaciones y especializaciones en los controles de acceso y se
facilite la modelización de la seguridad en sistemas complejos.
El control de acceso basado en roles permite expresar de forma sencilla y natural la
política de accesos a los recursos de una organización compleja. Al usar este modelo
como representación de la seguridad en un sistema colaborativo estamos integrando
los aspectos de seguridad con los funcionales.
Sin embargo pensamos que RBAC presenta una serie de carencias para el control
de acceso en procesos de naturaleza colaborativa:
• En RBAC la naturaleza de los roles puede ser denominada estática, ya que carecen
de flexibilidad y sensibilidad para el entorno en el cual son usados.
• RBAC soporta la noción de roles activos para un usuario con el concepto sesión,
obteniendo a partir de estos roles activos el conjunto de permisos disponibles para
un usuario, pero no tiene en consideración las sesiones establecidas por otros
usuarios en el sistema, es decir que el modelo no engloba todo el contexto asociado
con el sistema. Por ejemplo, en un entorno educativo, RBAC no permite dar
temporalmente permisos exclusivos del rol Director al rol Subdirector como
consecuencia de la ausencia en el sistema de un usuario ejerciendo el rol Director.
• No es capaz de especificar un control de grano fino sobre usuarios individuales en
ciertos roles y sobre instancias de objetos individuales. Un escenario donde sería
preciso establecer un control de grano fino es, por ejemplo, en el ambiente de un
hospital donde se crea un grupo de trabajadores sanitarios para dar asistencia
médica a un paciente en concreto, en este caso sólo los miembros de este grupo
podrán tener acceso al expediente del paciente, además los miembros del grupo
que ejerzan el rol Celador no tendrán acceso a las pruebas médicas del paciente.
• En el escenario descrito anteriormente se observada la necesidad de establecer
permisos comunes a grupos de usuario. Esto es conseguido en el modelo RBAC
creando un rol especifico y asignando de forma individual este rol a cada usuario
Modelo de Control de Acceso en un Sistema Colaborativo – 229
perteneciente al grupo. La posibilidad de la existencia de un gran número de
grupos de usuarios en los sistemas colaborativos y que la mayoría de estos grupos
sean de carácter temporal, provoca que el sistema de control de acceso sea mas
difícil de comprender y de controlar.
A pesar de las limitaciones comentadas del modelo RBAC pensamos que puede ser
usado como modelo de partida para la definición del control de acceso en un sistema
colaborativo. En la sección 4 presentamos una propuesta de modelo de sistema
colaborativo que extiende el modelo RBAC con aspectos relacionados con la
estructura organizativa del sistema y con un modelo de sesión mas completo.
3 Arquitecturas basadas en Servicios Web
En los últimos años la mayoría de los procesos de negocio están cambiando debido
sobre todo a los cambios de mercado y a la integración con las nuevas tecnologías.
Estos cambios están provocando nuevas formas de ofrecer servicios a los clientes y de
inter-operar diferentes negocios entre sí. Como resultado de esto, los sistemas de
información están siendo modificados para usar la infraestructura proporcionada por
Internet. A nivel arquitectónico, aparecen diferentes subsistemas interconectados
colaborando, en muchos casos, para llevar a cabo actividades que anteriormente eran
realizadas de un modo centralizado. En este mismo nivel, ha habido también un
incremento del uso de arquitecturas basadas en servicios Web (WSA) para la
implantación de procesos de negocio localizados en diferentes empresas o para
procesos colaborativos realizados por diferentes usuarios/subsistemas en la misma
empresa.
Desde un punto de vista arquitectónico es importante separar los aspectos de
seguridad de los propios de aplicación, con objeto de tener un mayor control de la
ejecución de los mismos. Las arquitecturas basadas en servicios Web son una buena
plataforma para realizar esta separación.
Por otro lado, desde el punto de vista de la definición de los procesos de negocio es
importante separar los aspectos relacionados con el manejo del flujo de trabajo en la
organización y los aspectos que especifican el contexto de ejecución de cada uno de
esos procesos, de tal modo que se consiga una mayor flexibilidad en la administración
y gestión de procesos.
A nivel arquitectónico es necesaria la inclusión de un subsistema encargado
específicamente de cada uno de este conjunto de aspectos funcionales. En muchos
casos cada subsistema tiene que interactuar con el resto de sistemas por lo que una
buena solución a nivel arquitectónico puede ser la implementación de un servicio
Web, para cada subsistema, que de forma transparente puedan ser utilizado por el
resto del sistema
Basándonos en trabajos previos, realizados en nuestro grupo, en arquitecturas
software [6] [7] y más concretamente en arquitecturas para sistemas colaborativos [8],
en la figura 2 se presenta una propuesta arquitectónica parcial en la que se reflejan
los tres servicios relacionados con la seguridad: un servicio Web de Autorización, un
servicio Web Manejador de Tareas y un servicio Web de Sesión.
230 – Sánchez, M., Jiménez, B., Gutiérrez, F.L, Paderewski, P., Isla, J.L.
Para observar el funcionamiento de la arquitectura vamos a describir, de forma
rápida, como se produce la comunicación y coordinación entre los tres servicios en un
sistema empresarial de gestión de un banco. Nos vamos a centrar en el proceso de
realización de préstamos. Esta aplicación forma parte de nuestro sistema y al ser
desarrollada se ha derivado parte de su funcionalidad a los servicios que proporcionan
la gestión del control de acceso en el sistema.
Por ejemplo en el caso del proceso de realización de un préstamo, la aplicación se
tiene que comunicar con el servicio Web manejador de tareas para saber cual es la
actividad inicial que debe realizar el usuario dentro de este proceso de negocio ,por
ejemplo puede ser la comprobación de los datos del cliente que solicita el préstamo.
Previamente, al inicializar la aplicación, se habrá conectado un usuario con lo que
la aplicación habrá generado una petición al servicio de autorización para determinar
si bajo el rol en el que se encuentra (depende del usuario concreto y de su proceso de
inicio) puede realizar la definición de un nuevo préstamo.
El servicio de manejador de tareas consulta al servicio Web de sesión para obtener
el uso actual del sistema, por ejemplo, para saber qué tareas del proceso de realización
de préstamos ya han sido realizadas, si este proceso se inició con anterioridad.
Posteriormente la aplicación seguirá con el resto de procesos que recibe del
manejador de tareas derivando todo el control de acceso de recursos y actividades a
los servicios Web ofertados por la arquitectura.
Fig 2. Servicios de autorización, sesión y manejador de tareas
La arquitectura propuesta está basada en el paradigma MDA (Model Driven
Arquitecture) de tal modo que la funcionalidad de los servicios Web esta dirigida por
un modelo de la organización, el cual contiene toda la información necesaria para
llevar a cabo las operaciones de los propios servicios. Los diferentes servicios
proporcionan operaciones para mantener y hacer evolucionar, en tiempo de ejecución,
este modelo.
En las siguientes subsecciones se realiza una descripción de las operaciones más
importantes que ofertan cada uno de estos servicios.
Modelo de Control de Acceso en un Sistema Colaborativo – 231
3.1 Servicio Web Autorización
El servicio Web Autorización mantiene información acerca de las políticas de
autorización implantadas en el sistema. Este servicio lo utilizarán otros sistemas y
aplicaciones en la empresa, principalmente, para saber si las aplicaciones que están
activas en el sistema tienen acceso a recursos en base a las actividades que están
realizando en la actualidad. En el caso de los sistemas colaborativos es un elemento
importante ya que se comparten numerosos recursos y es necesario coordinar el
acceso a ellos.
Dicho servicio ofrece las siguientes operaciones:
• Registrar actores y roles.
• Enlazar actores a roles y permisos a roles.
• Cambiar los roles jugados por un actor.
• Comprobar el acceso a recursos acorde con los permisos activos de actor.
• Comprobar el acceso a una actividad acorde con los permisos activos de actor.
Se implementan dos tipos de acceso al servicio, por un lado “el modo de acceso
usuario” usado por aplicaciones para el control de acceso a recursos compartidos, y
por otro “el modo de acceso administrador” con el que se pueden realizar
modificaciones en los modelos de autorización que maneja el servicio.
3.2 Servicio Web Manejador de Tareas
El servicio Web para manejo de tareas es el encargado de coordinar las actividades
(procesos de negocio) que realizan los diferentes elementos dentro del sistema y de
mantener un modelo de tareas con información sobre las tareas que se puede realizar
y las actividades y subactividades que forman cada una de ellas.
El manejo de un proceso de negocio basado en tareas debe abordarse teniendo en
cuenta la unión de dos grupos de aspectos [9]:
• Aspectos Declarativos: Aspectos relativos a ‘qué’ es lo que hay que hacer. Se
recoge aquí todo lo relacionado con las especificaciones de entrada/salida a cada
actividad y las relaciones entre actividades y acciones, para cada una de las tareas.
En el caso particular de los sistemas colaborativos además se recoge la
especificación de los objetivos que se desean alcanzar en un proceso colaborativo.
• Aspectos Operacionales: Aspectos relativos a ‘como’ se deben de hacer las cosas.
Recogiendo todo lo relativo a la especificación detallada de cada paso en la
secuencia de sub-actividades, es decir el desarrollo de cada sub-actividad o acción
en particular.
Este servicio permite a las aplicaciones existentes en el sistema, derivar parte de su
lógica interna de proceso al servicio y de esta forma facilitar su desarrollo, inclusión
y adaptación al modelo de negocio del sistema.
Podemos diferenciar dos tipos de operaciones, “operaciones de registro”,
destinadas a crear el modelo de tareas:
• Registrar tareas.
• Asociar actividades con tareas y roles.
232 – Sánchez, M., Jiménez, B., Gutiérrez, F.L, Paderewski, P., Isla, J.L.
• Registrar las tareas y roles interrumpibles de otras tareas.
• Asociar recursos a una actividad.
• Registrar los estados de terminación de una actividad.
• Registrar los estados de iniciación de una actividad.
• Especificar los objetivos a alcanzar como resultado de un proceso colaborativo.
Y “operaciones de consulta”, para la obtención de información del modelo:
• Obtener la actividad siguiente a realizar dada una actividad precedente y su estado
de terminación
3.3 Servicio Web Sesión.
El servicio Web sesión mantiene una representación del uso dinámico del sistema.
Este servicio se encarga de registrar las tareas realizadas/activas por cada actor bajo
un determinado rol junto con una serie de elementos asociados con el contexto en el
que se realizan esas actividades.
Podemos controlar el estado de cada usuario/subsistema por el uso de la
información almacenada durante la sesión. Se almacena información del tipo: actores
conectados, roles jugados por cada usuario, recursos usados, actividades realizadas en
la sesión actual, etc.
Este servicio ofrece las siguientes funciones:
• Obtener las actividades finalizadas en una tarea.
• Obtener las instancias activas de una actividad.
• Obtener para un actor el rol activo en la realización de una tarea.
• Obtener el estado de terminación para una actividad dentro de una tarea.
• Obtener qué actor y con qué rol ha finalizado una actividad.
• Obtener las actividades activas de una tarea, los actores que la ejecutan y el equipo
al que pertenecen.
• Obtener los roles activos de los actores de un equipo.
• Registrar la finalización de una actividad en una tarea.
• Registrar la activación de una actividad en una tarea indicando el actor y equipo de
la activación.
• Registrar el rol asociado a un actor para una actividad en una tarea.
4 Modelo de Organización
La arquitectura que hemos propuesto basa su funcionamiento en la definición de un
modelo del sistema capaz de mantener toda la información que se necesita para que
los servicios Web puedan realizar las operaciones definidas.
Como mostramos en la sección 2 el modelo de control de acceso RBAC tiene
ciertas limitaciones a la hora de representar aspectos importantes de los sistemas
colaborativos, por ello nosotros hemos extendido el modelo incluyendo elementos
estructurales como la organización y elementos dinámicos como las dependencias
entre roles y organizaciones.
Modelo de Control de Acceso en un Sistema Colaborativo – 233
La figura 3 muestra un modelo conceptual (usando un diagrama de clases UML) el
cual permite describir la organización social del sistema. Este modelo refleja los
elementos más importantes que aparecen en cualquier organización, así como
aquellos que tradicionalmente han sido usados en el modelado de sistemas
colaborativos [10].
Este modelo conceptual define una organización como una estructura de grupos
(donde un grupo puede ser por ejemplo una compañía, un departamento, un equipo de
actores quienes temporalmente toman parte en tareas comunes, etc.) así como un
conjunto de roles y dependencias funcionales entre ellos. De esta forma, podemos
modelar asociaciones de diferente naturaleza, por ejemplo, la posibilidad de que un
actor pase de un rol a otro.
El modelo describe una sesión como el conjunto de tareas que está ejecutándose en
el momento actual registrando para cada tarea el actor que la está realizando, el rol
bajo el cual la realiza y los recursos que se están utilizando.
Fig 3. Modelo de organización conceptual.
Desde un punto de vista estructural (dependencias estructurales), una organización
puede ser incluida dentro de otra organización (por ejemplo, un departamento puede
ser parte de una compañía).
El concepto actor incluye individuos (un usuario, un agente software, etc.) y
grupos. Un actor individual forma parte al menos de un grupo, y un actor (grupal o
individual) juega, en un momento determinado, al menos un rol en una organización.
Jugar un rol implica que el actor es responsable de realizar las tareas asociadas con
ese rol.
Asumimos implícitamente que un actor debe tener la capacidad necesaria y los
permisos para llevar a cabo las correspondientes tareas y usar los recursos asociados.
Además, las dependencias funcionales en este modelo nos permiten especificar y
controlar los cambios de rol que un actor puede experimentar en un sistema. Por esta
234 – Sánchez, M., Jiménez, B., Gutiérrez, F.L, Paderewski, P., Isla, J.L.
razón, podemos decir que este modelo permite un acceso de control dinámico basado
en roles. Desde un punto de vista de dependencias de actividad se permite especificar
una descomposición jerárquica de tareas, permitiendo controlar y especificar de forma
dinámica el flujo de trabajo en el sistema.
5 Conclusiones
En este trabajo se ha puesto de manifiesto la utilidad de separar los aspectos de
seguridad de los propios de aplicación dentro de un proceso de negocio colaborativo
con objeto de tener un mayor control en la ejecución.
Se ha propuesto una arquitectura basada en servicios Web como plataforma para
realizar dicha separación. Tomando como referente el modelo RBAC hemos
presentado un servicio Web de autorización basado en roles. Para dar soporte a lógica
interna del proceso de negocio se han propuesto dos servicios Web, un servicio Web
manejador de tareas para dar soporte a aspectos de coordinación y un servicio Web
sesión para representar el estado de cada usuario/subsistema en el sistema.
Como apoyo a esta arquitectura se ha definido un modelo de organización del
sistema que permite representar aspectos estructurales como la organización y
elementos dinámicos como las dependencias entre roles y organizaciones.
En la actualidad estamos trabajando en la propuesta de una arquitectura completa
para sistemas colaborativos en la que incluiremos los servicios Web definidos en este
artículo.
En el caso concreto del control de acceso pensamos que es muy interesante poder
aplicar patrones conceptuales durante su modelado de forma que podamos definir
políticas de control de acceso generales que puedan ser aplicadas en cualquier
sistema. Esto reduce el esfuerzo de modelización y permite generar soluciones de
diseño mas optimizadas.
Agradecimientos
Este trabajo esta financiado por la Comisión Interministerial para la Ciencia y la
Tecnología (CICYT) proyecto AMENITIES - TIN2004-08000-C03-02.
Bibliografía
1. Shen, H., Dewan, P.: Access control for collaborative environments. In: Proceedings of the
1992 ACM Conference on Computer-Supported Cooperative Work, (CSCW '92) Toronto,
Ontario, Canada. ACM Press, New York, NY, (1992) 51-58.
2. Tolone, W., Ahn, G., Pai, T., Hong, S.:Access control in collaborative systems.”. ACM
Comput. Surv. 37, 1 (2005) 29-41.
3. Ellis, C.A., Gibbs, S.J., Rein, G.L.: Groupware: Some Issues and Experiences.
Communications of the ACM Vol. 34, No. 1 (1991) 38-58
Modelo de Control de Acceso en un Sistema Colaborativo – 235
4. Sandhu, R. S., Coyne, E. J., Feinstein, H. L., Youman, C. E.: Role-Based Acces Control
Models. Computer 29, 2 (1996) 38-47.
5. Ferraiolo, D. F., Sandhu, R., Gavrila, S., Kuhn, D. R., Chandramouli, R. Proposed NIST
standard for role-based access control. ACM Trans. Inf. Syst. Secur. 4, 3 (2001) 224-274.
6. Garrido, J.L., Paderewski P., Rodríguez M.L., Hornos M., Noguera M.: A Software
Architecture Entended to Design High Quality Groupware Applications, In Proceedings of
the ICSE Research and Practice (2005) 59-65
7. Paderewski, P., Rodríguez M.J, Parets J.: An Architecture for Dynamic and Evolving
Cooperative Software Agents, Computer Standards & Interfaces, Vol. 25, Elsevier Science
(2003) 261-269
8. Gutiérrez F.L, Isla , J.L., Paderewski, J.l. , Sánchez, M.: Organization Modelling to Support
Access Control for Collaborative Systems. In The 5th international workshop on
System/Software architectures (IWSSA'06) ,Las Vegas, Nevada, USA. (2006) 26-29
(Aceptado pendiente de publicación)
9. Terai, K., Izumi, N., Yamaguchi, T.: Coordinating Web Services based on business models.
In: Proceedings of the 5th international Conference on Electronic Commerce,(ICEC ´03)
Pittsburgh, Pennsylvania, Vol. 50. ACM Press, New York, NY,(2003) 473-478.
10. van Welie, M., Van der Veer, G.C.: An Ontology for Task World Models, In:
Design,Specification and Verification of Interactive System’98, Springer Computer
Science,(1998)