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, 2joseluis.isla@uca.es 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)