Sunteți pe pagina 1din 97

Universidad de La Rioja

Departamento de Matemticas y Computacin

Memoria para optar a la concesin de la suficiencia investigadora y el Diploma de Estudios Avanzados

Cdigo seguro en Arquitecturas Orientadas a Servicios

Autor: Emilio Rodriguez Priego

Directores: Julio J. Rubio Garcia Francisco J. Garcia Izquierdo


3 de julio de 2007

ndice general
1. Descripcin del tema de investigacin . . . . . . . . . . . . . . . 1.1. Introduccin . . . . . . . . . . . . . . . . . . . . . . . . . 1.2. Motivaciones . . . . . . . . . . . . . . . . . . . . . . . . . 1.3. Objetivos concretos . . . . . . . . . . . . . . . . . . . . . Contribucin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.1. Planteamiento del problema . . . . . . . . . . . . . . . . . 2.1.1. Modelos de referencia y arquitecturas . . . . . . 2.2. Estudio previo y punto de partida . . . . . . . . . . . . . 2.3. Modelo de referencia de cdigo seguro basado en SOA . . 2.3.1. Comparacin con SOA-RM . . . . . . . . . . . . 2.3.2. mbito de aplicacin . . . . . . . . . . . . . . . 2.4. WSbSC-RM: Modelo de referencia de la Arquitectura de Cdigo seguro basado en Servicios Web . . . . . . . . . . 2.4.1. Comparacin con WSA . . . . . . . . . . . . . . 2.4.2. Descripcin general de WSbSC-RM . . . . . . . 2.4.3. PSC y PSC-Cert . . . . . . . . . . . . . . . . . . 2.4.4. Aplicacin de WSbSC a la Implementacin de Servicios Web . . . . . . . . . . . . . . . . . . . 2.5. Modelos de intercambio de informacin con WSbSC . . . 2.6. WSbSS: Estado seguro basado en Servicios Web . . . . . 2.6.1. PSS y PSS-cert . . . . . . . . . . . . . . . . . . . 2.6.2. Dualidad Cdigo-Estado . . . . . . . . . . . . . 2.7. Objetos seguros basados en Servicios Web . . . . . . . . . 2.7.1. Aproximacin a PSO y PSO-cert . . . . . . . . . 2.8. Acceso legal al estado. WSbSO-RM . . . . . . . . . . . . 2.9. Directrices para la conformidad con WSbS* . . . . . . . . 2.10. Modelo de seguridad de WSbS* . . . . . . . . . . . . . . . 2.10.1. Caractersticas del modelo de seguridad . . . . . 2.10.2. Niveles de Seguridad . . . . . . . . . . . . . . . . 2.10.3. Modos de seguridad . . . . . . . . . . . . . . . . 2.10.4. Mecanismos de seguridad . . . . . . . . . . . . . 2.10.5. Sujetos de seguridad . . . . . . . . . . . . . . . . 2.10.6. Grados de seguridad . . . . . . . . . . . . . . . . 2.11. Implementacin del modelo . . . . . . . . . . . . . . . . . 2.11.1. Implementacin de las poltica de seguridad . . . 2.11.2. Implementacin de PS*-certs . . . . . . . . . . . 2.12. Consideraciones sobre el rendimiento . . . . . . . . . . . . 3 3 4 4 5 5 5 5 7 7 10 11 11 13 16 18 19 22 23 25 25 25 27 29 29 30 31 31 33 33 33 34 36 36 38

2.

3.

Conclusiones y trabajo futuro . . . . . . . . . . . . . . . . . . . .

39 42 46 49 64 65

Bibliografa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A. Glosario B. Ejemplo de codicacin en XML de PS*-certs C. Publicaciones y Trabajos presentados en Congresos D. Presentaciones

1.
1.1.

Descripcin del tema de investigacin


Introduccin

Los trminos Servicios web y Service Oriented Architecture (SOA) vienen siendo utilizados con mucha frecuencia en los ltimos aos. Ambos trminos se reeren a reas de conocimiento que estn recibiendo un enorme impulso por la comunidad de especialistas en tecnologas de la informacin y, muy especialmente, por parte de los proveedores de soluciones tecnolgicas. Debe ser resaltado que los dos trminos parten de deniciones sencillas e intuitivas que recuerdan a viejos conceptos y por tanto, al contrario de lo que ocurri con otros hitos en la historia de la computacin como la programacin estructurada o la orientacin a objetos, estrictamente hablando no parecen plantear nuevos paradigmas sobre los que iniciar una nueva etapa dentro del mbito de las tecnologas de la computacin. Esta aparente simplicidad y su semejanza o analoga con viejos conceptos ha creado no pocas confusiones sobre sus verdaderas implicaciones y sobre su verdadero signicado y utilizacin. De hecho, en la actualidad, como ya ocurri anteriormente con otros paradigmas, se sobreutilizan y se etiquetan exageradamente todo tipo de soluciones mediante SOA y servicios web. Entonces, el entusiasmo que, durante varios aos ya, generan estos conceptos est justicado?. La respuesta no puede ser otra que armativa.SOA y los Servicios web tienen el gran mrito de haber abierto el camino para solucionar un problema muy sencillo en su planteamiento y en absoluto trivial en su solucin: la interoperabilidad entre sistemas potencialmente remotos y heterogneos. SOA ha aportado la visin conceptual que permite comprender el modelo de intercomunicacin mediante Servicios web. Tambin, al n, est permitiendo alcanzar la ansiada interoperabilidad entre sistemas heterogneos sin las ataduras de las soluciones comerciales. En este contexto han surgido innidad de lneas de investigacin, muchas de ellas replanteando viejos problemas en el nuevo marco que ofrecen estas dos nuevas reas de conocimiento, y ms concretamente, es la seguridad uno de los aspectos que ms inters despierta sobre todo porque para llevar a cabo con xito proyectos prcticos este aspecto es crtico. Alrededor de SOA y, concretamente, de los servicios web, han aparecido centenares de estndares promovidos por organismos internacionales como el W3C u OASIS, y una gran parte de estos estndares ponen su punto de atencin en la seguridad. La utilizacin de estndares en s misma no garantiza alcanzar el objetivo de la interoperabilidad en un entorno seguro [42, 10], sino que adems los estndares deben ser utilizados adecuadamente y de una manera integrada y todo ello no es en absoluto una tarea fcil. Por otro lado, el estudio de la seguridad al ser un concepto muy amplio y complejo suele referirse a un mbito determinado. Este hecho viene corroborado porque si bien existen diversos estndares relativos a seguridad en entornos SOA y servicios web, an no se ha desarrollado un modelo estndar de seguridad que integre todos ellos y permita su utilizacin de una

manera conjunta y completa, probablemente debido a que an existen bastantes mbitos donde no se han desarrollado estndares de seguridad aplicables.

1.2.

Motivaciones

Los aspectos de seguridad de SOA y Servicios web relacionados con el cdigo, en sus distintas vertientes (como dato, como implementacin de servicios, etc.), son hoy en da de los menos estudiados comparados con otros mbitos, a pesar de que la seguridad del cdigo s ha sido estudiada en los ltimos aos desde otros puntos de vista (agentes mviles, movilidad del cdigo, etc.). sta ha sido una de las principales motivaciones para realizar esta investigacin. Otra razn ha sido el convencimiento de que SOA y Servicios web pueden facilitar la interoperabilidad del cdigo de una manera segura, al igual que ha ocurrido cuando se han aplicado a otros problemas como el intercambio seguro de datos entre aplicaciones. La aplicacin adecuada de estndares basados en XML efectivamente abre perspectivas muy interesantes cuando se analiza la seguridad del cdigo. Por ltimo, la mencionada ausencia de un modelo unicado de seguridad ampliamente aceptado tambin es un estmulo para investigar un modelo que pueda ser aplicable al cdigo y por extensin a objetos, contribuyendo por tanto a cubrir uno de los aspectos menos estudiados. Desde un punto de vista personal, el cdigo y su analoga con los datos (dualidad dato-programa), la orientacin a objetos y la seguridad (modelos, principios, tecnologas) siempre han despertado mi curiosidad y los estudi con inters durante mis estudios de ingeniera de telecomunicaciones, rea de informtica. Por otro lado, en el mbito laboral he tenido la oportunidad de trabajar en proyectos donde estos aspectos, especialmente el de la seguridad, han sido importantes. En especial, mi ocupacin actual como Auditor de Tecnologas de la Informacin en un Organismo adscrito al Gobierno de La Rioja me ha permitido conocer desde un punto de vista bastante amplio la problemtica de la falta de interoperabilidad del software, los serios problemas de seguridad que se presentan en la prctica y las grandes dicultades que tienen, por ejemplo, las Administraciones Pblicas para intercambiar y reutilizar cdigo an en los casos ms sencillos. La identicacin de casos reales en los que un modelo de seguridad con un enfoque SOA y de Servicios web puede ser aplicado representa un estmulo ms para esta investigacin.

1.3.

Objetivos concretos
Denicin de un modelo de referencia que sirva como base para comprender cules son las relaciones entre los diferentes actores, conceptos, relaciones y ujos que intervienen en una interaccin segura de cdigo y datos.

Los objetivos de este trabajo de investigacin son resumidos a continuacin:

Particularizar el modelo dentro de la perspectiva de SOA y Servicios web proponiendo un modelo de seguridad para la vericacin de cdigo en distintos escenarios. Extender el modelo del intercambio seguro de cdigo mediante servicios web a la combinacin de cdigo ms estado (objetos).

2.
2.1.

Contribucin
Planteamiento del problema

En esta seccin vamos a describir algunos conceptos bsicos (que pueden encontrarse en diversas fuentes tales como [2, 25]) relacionados con la investigacin y que son necesarios para comprender mejor el punto de partida para el planteamiento del problema, adems en el Glosario (Apndice A) se resumen todos los conceptos utilizados. 2.1.1. Modelos de referencia y arquitecturas

Creemos que es importante distinguir entre dos conceptos que habitualmente se confunden o utilizan indistintamente y que sern utilizados en nuestra investigacin: Modelo de referencia conjunto mnimo de conceptos, axiomas y relaciones dentro de un determinado dominio y que es independiente de estndares especcos, tecnologas, implementaciones y otros detalles concretos. Este conjunto forma un conjunto abstracto que permite comprender las principales relaciones entre las entidades de un entorno y el desarrollo de arquitecturas especcas que usen estndares o especicaciones aplicados a ese entorno . Se pueden distinguir dos tipos bsicos de arquitectura: Arquitectura de referencia estructura que ofrece una solucin abstracta a un problema en un determinado dominio. Arquitectura concreta implementacin especca de una solucin basada en arquitecturas de referencia, patrones y requisitos adicionales, incluidos los que vienen determinados por el entorno tecnolgico.

2.2.

Estudio previo y punto de partida

El punto de partida para la realizacin de la investigacin fue un estudio previo de los estndares relacionados con Servicios web y el modelo de referencia SOA (en adelante SOA-RM). Se analizaron ms de 30 estndares, muchos de ellos relacionados con la seguridad en Servicios web. Las principales conclusiones del estudio fueron: Aunque algunos estndares no haban sido an aprobados ocialmente y haba un grupo de ellos que an estn en fase de aprobacin, existe un grupo bsico (SOAP, WSDL, WS-Security, SAML, XML-signature, etc.) que tienen la suciente madurez como para que en la prctica estn siendo 5

utilizados con xito y por tanto puedan ser tenidos en cuenta al abordar la investigacin. No hubo un gran consenso respecto a una arquitectura de servicios web. El W3C trabaj en dicha cuestin tenindose como resultado no un estndar sino una Nota del grupo de trabajo [2] titulada Web Services Architecture (en adelante WSA) que, aunque contiene aspectos muy interesantes, reconoce que hay cuestiones an no consensuadas y preguntas abiertas. As, por ejemplo, sobre la seguridad, aunque es tratada con cierta extensin en un apartado, se reconoce en la introduccin que En este momento, no existen unas especicaciones ampliamente reconocidas sobre Seguridad en servicios web. Posteriormente, OASIS, basndose en dicha Nota aprob como estndar un modelo de referencia ms genrico [25] pero que igualmente no aborda la cuestin de denir el modelo de seguridad bsico en un entorno SOA. Tanto los estndares relacionados con la seguridad en servicios web como las referencias a la seguridad en la arquitectura de servicios web y el SOA-RM se centran exclusivamente en la seguridad asociada al dato o al mensaje pero en ningn caso abordan el problema de la seguridad del cdigo, el cual como se indicar ms adelante, es en la prctica uno de los aspectos bsicos de la seguridad. De hecho, tal como han constatado diversos estudios, el cdigo es una de las fuentes principales de amenazas a la seguridad [15, 44]. De esta forma se identica, ya en este estudio previo, la necesidad de ahondar ms profundamente sobre la seguridad del cdigo en el mbito de los servicios web y SOA. Se toma por tanto como punto de partida el SOA-RM y WSA, en especial el primero ya que ha sido aprobado nalmente como estndar recientemente y cuenta con una mayor aceptacin. Por otro lado, para ahondar ms sobre la seguridad del cdigo se realiza un estudio de las cuantiosas referencias relativas a este aspecto dentro de dos reas bien denidas: el cdigo mvil y los agentes mviles: Cdigo mvil La movilidad del cdigo ha sido investigada durante mucho tiempo, principalmente en el mbito de los sistemas distribuidos. En [4] se dene como la capacidad para recongurar dinmicamente y en tiempo de ejecucin el vnculo entre los componentes software de una aplicacin y su localizacin fsica dentro de una red. Agentes mviles El concepto de agente tambin ha sido estudiado en el pasado desde el punto de vista de los sistemas distribuidos y, sobre todo, desde el enfoque de la inteligencia articial. Tomando como referencia este ltimo, los agentes son piezas genricas de software con las siguientes caractersticas [5, 35]: 1. Su funcionamiento es autnomo, es decir, realizan el proceso independientemente, sin necesidad de intervencin humana.

2. Pueden aprender en funcin de su entorno. Su comportamiento puede mejorar a lo largo del tiempo cuando interactuan con su entorno y otros agentes o personas. 3. Pueden comunicarse entre s, con otros sistemas o con personas. Los agentes mviles que pueden considerarse como un caso particular de cdigo mvil, son agentes que pueden viajar de un equipo a otro, generalmente enviados por usuarios nales a los cuales devuelven al nal sus resultados. La seguridad del cdigo referida a estos dos conceptos (cdigo mvil y agentes mviles) tambin ha sido estudiada profusamente [5, 3, 34, 46] y se ha centrado principalmente en la resolucin de dos problemas bsicos que surgen cuando un cdigo viaja a travs de una red para ser ejecutado en un entorno de ejecucin remoto: Cdigo malicioso Se trata del punto de vista del entorno de ejecucin que debe abordar los problemas de seguridad que puede plantear la ejecucin de un cdigo externo cuyo comportamiento debe ser vigilado para que no realice operaciones potencialmente peligrosas, equivocadas o indebidas. Entorno de ejecucin malicioso Aqu por el contrario se aborda el problema de seguridad desde el punto de vista del cdigo que viaja a un entorno de ejecucin que podra afectar a su funcionamiento. Los ataques pueden ser de diversa naturaleza [20] y algunos autores argumentan que la proteccin total del cdigo puede ser incluso imposible si no se establecen unas restricciones previas. Generalmente las soluciones propuestas a los distintos problemas de seguridad pueden clasicarse como soluciones preventivas o de validacin posterior. En cualquier caso, la gran mayora de propuestas se centra en problemas muy concretos y generalmente en entornos locales. No existe una amplia bibliografa abordando el problema desde el punto de vista de la arquitectura de servicios web o SOA.

2.3.
2.3.1.

Modelo de referencia de cdigo seguro basado en SOA


Comparacin con SOA-RM

En este apartado, con el n de evitar confusiones sobre la terminologa, repasaremos los principales conceptos incluidos en SOA-RM que estn relacionados con la investigacin. El modelo de referencia SOA se basa en siete conceptos bsicos: Servicio, Visibilidad, Descripcin del Servicio, Contexto de ejecucin, Efectos en el mundo real, Interaccin y Contratos/Polticas. El concepto central del modelo es el Servicio que viene denido como: Servicio Mecanismo que permite el acceso a un conjunto de una o ms capacidades, en el que el acceso se proporciona por una interfaz normalizada 7

y cuyo uso es ejercido consistentemente mediante restricciones y polticas especicadas en la denicin del servicio. Para nuestro estudio nos centramos en cuestiones planteadas en la descripcin de alguno de estos conceptos de SOA-RM que es necesario revisar para poder ampliar este modelo hacia un modelo que soporte cdigo seguro. En primer lugar en la descripcin de Servicio, se establece que
Un servicio es opaco en el sentido de que su implementacin es tpicamente oculta para el consumidor del servicio, excepto para los modelos de informacin expuestos a travs del interfaz del servicio y la informacin requerida por los consumidores del servicio para determinar si ste es apropiado a sus necesidades.

Y aade,
Las acciones internas que los proveedores y consumidores de servicios realizan como resultado de su participacin en las interacciones del servicio son, por denicin, privadas y fundamentalmente desconocidas, entendindose por desconocidas que participantes externos no pueden ver las acciones privadas de otros y, ms an, que no deberan tener conocimiento explcito de ellas.

Es decir, SOA-RM no prohbe que la implementacin no sea oculta pero indica que lo habitual es que el consumidor no conozca tal implementacin. Respecto a Efectos del mundo real (de Real World Eects en [25]), indica que:
Como consecuencia de la invocacin de un servicio se producen uno o ms efectos del mundo real, pudiendo ser stos: 1. La informacin devuelta en respuesta a una peticin de dicha informacin 2. Un cambio en el estado compartido de las entidades denidas 3. Alguna combinacin de 1 y 2 El estado compartido no necesariamente se reere a las variables de estado determinadas que son almacenadas en un soporte fsico, sino que representan la informacin compartida sobre las entidades afectadas. Por el contrario, nosotros nos centramos en el conjunto de hechos compartidos por las partes, el estado compartido. Las acciones de los proveedores y consumidores del servicio conducen a modicaciones de este estado compartido; y el efecto del mundo real de una interaccin de servicio es la acumulacin de los cambios en el estado compartido.

En su denicin de Interaccin introduce otros conceptos como:


El Modelo de informacin de un servicio es la caracterizacin de la informacin que puede ser intercambiada con el servicio. Slo informacin y datos que son potencialmente intercambiados con un servicio son, en general, incluidos dentro del modelo de informacin del servicio. El Modelo de comportamiento caracteriza el conocimiento sobre las acciones, respuestas y dependencias temporales entre las acciones de un servicio. (...). Una gran parte del comportamiento que se produce como resultado de una accin puede ser privado, sin embargo, la visin pblica del servicio incluye efectivamente los efectos producidos por las acciones.

Figura 1: Relacin entre conceptos en SOA-RM

Finalmente, SOA-RM introduce los conceptos de Poltica y Contrato, como.


Una Poltica representa algn requisito o condicin sobre el uso, despliegue o descripcin de una entidad denido para cualquier participante. Un contrato representa un acuerdo entre dos o ms partes.

Ambos, pueden tambin restringir aquellos Efectos del mundo real que se esperan cuando se usa un servicio. En la gura 1, se representan la totalidad de las relaciones propuestas entre los siete conceptos denidos en SOA-RM, as como otros subconceptos asociados. Nuestra propuesta es introducir nuevos conceptos que amplen SOA-RM para permitir abordar la seguridad del cdigo en una arquitectura SOA: 1. El cdigo como dato: en algunas situaciones ( 2.3.2) la informacin intercambiada a la que alude el modelo es cdigo. Incluso, como veremos ms adelante, puede tratarse del cdigo que implementa el servicio, teniendo que ser en ese caso conocido por la otra entidad (consumidor o proveedor). 2. Proceso compartido: es el concepto anlogo al estado compartido que indica SOA-RM. De manera similar a cmo el proveedor y el consumidor comparten un estado que reeja un efecto en el mundo real, tambin puede denirse como efecto de un servicio la comparticin del proceso entre el proveedor y el consumidor. As por ejemplo imaginemos un consumidor que solicita un servicio de reserva de vuelos a un proveedor. Dicho consumidor podra poseer una agenda en la que almacena sus citas. Un posible escenario (cuyo modelo genrico se describe en 2.7) es aquel donde el proceso se comparte entre consumidor y proveedor de tal manera que el consumidor proporciona un objeto agenda con sus respectivos mtodos que interacciona con la implementacin del servicio de reserva de vuelo del proveedor. Como resultado se efecta la reserva y la anotacin de una cita en la agenda para el da del vuelo. En denitiva, el proceso ha sido compartido tanto por el consumidor como el proveedor. El Efecto del mundo real producido no slo ha sido la comparticin de un estado conocido por ambas partes (la reserva de vuelo) sino tambin la comparticin de un proceso tambin conocido por ambas partes (el proceso de anotacin en la agenda y el proceso de obtencin del billete del vuelo). 3. Polticas y contratos sobre cdigo: las polticas y los contratos que se aplican a Servicios tambin pueden reejar restricciones sobre el cdigo como dato intercambiado (portabilidad) y/o como implementacin de las acciones de un servicio. Como puede observarse en la gura 2, nuestro enfoque consiste en aplicar la dualidad dato-cdigo y estado-proceso al modelo de referencia SOA. Esto permite asociar este modelo con las reas de cdigo y agentes mviles indicadas previamente y sienta las bases para plantear un modelo de seguridad donde adems de la seguridad del dato tambin se considera la seguridad del cdigo como elemento fundamental para alcanzar el mayor grado de seguridad en una interaccin de servicios. 2.3.2. mbito de aplicacin

Aunque nuestro modelo es virtualmente aplicable a cualquier escenario SOA en el que se considere el cdigo como un aspecto importante de seguridad, 10

Figura 2: Comparacin con SOA hay determinados mbitos de aplicacin en los que la visibilidad del cdigo, su integridad y/o su portabilidad cobran una enorme importancia, puesto que bien slo la integridad del cdigo, el cdigo en s, la fuente del cdigo o todos estos elementos, se ofrecen o intercambian como parte de los servicios proporcionados por el proveedor de los mismos. Ejemplos tpicos de estos mbitos de aplicacin son los siguientes: Servicios de proceso distribuido Servicios de albergue u hospedaje de procesos. Un caso particular, es el alquiler de procesadores para realizar clculos que requieren una alta capacidad de proceso Servicios de auditora / certicacin / validacin de cdigo por parte de una o diversas entidades reconocidas Servicios de homologacin de cdigo Bibliotecas de cdigo accesibles y reutilizables tanto de cdigo abierto como comercial Servicios de optimizacin de cdigo

2.4.
2.4.1.

WSbSC-RM: Modelo de referencia de la Arquitectura de Cdigo seguro basado en Servicios Web


Comparacin con WSA

SOA-RM tiene su principal aplicacin en WSA, cuyo modelo ya citado es anterior a SOA-RM y aunque no fue aprobado como estndar introduce y dene conceptos que sern tiles para nuestro estudio. Aqu el concepto central es Servicio web, denido como: Servicio web sistema software diseado para soportar una interaccin extremo a extremo interoperable sobre una red. Los servicios web tienen un

11

Figura 3: Esquema general de servicios web interfaz descrito mediante un formato que puede ser procesado automticamente (concretamente WSDL). Otros sistemas pueden interacturar con un servicio web tal como ha sido denido en su descripcin, usando mensajes SOAP, tpicamente transmitidos usando HTTP y serializacin XML en conjuncin con otros estndares relacionados con la Web. WSA, a diferencia de SOA-RM, hace una distincin entre Personas u Organizaciones y agentes: Persona u organizacin : se reere a personas u organizaciones reales que pueden ofrecer o solicitar servicios web, pertenecer a un determinado dominio en el que pueden establecer polticas que gobiernen los recursos que poseen. Agente : es un programa que acta en nombre de una persona u organizacin. No debe confundirse este concepto de Agente con el ya indicado proveniente del rea de inteligencia articial que se reere a cdigo mvil autnomo. Por otro lado, [1] indica dos deniciones posibles del concepto de actor: 1. Persona u organizacin que puede ser propietaria de agentes que solicitan el uso o proveen servicios web. 2. Entidad fsica o conceptual (por ej. personas, organizaciones, mquinas, software, etc.) que puede realizar acciones. Un actor puede asumir uno o ms roles. Un actor en un nivel de abstraccin puede ser visto como un rol en un nivel de abstraccin inferior. En la Figura 3 se describe un esquema general de funcionamiento de la arquitectura de servicios web

12

2.4.2.

Descripcin general de WSbSC-RM

Una vez vistos los conceptos bsicos en SOA-RM y WSA, veamos nuestra denicin de un modelo de referencia de una arquitectura basada en servicios web orientada a cdigo seguro y que denominaremos WSbSC-RM (Web Services based Secure Code Reference Model). En WSbSC-RM el concepto central es el cdigo tal como ha sido denido tradicionalmente [43], pero, como vemos a continuacin, con algunas caractersticas especcas: Puede ser portable Puede ejecutarse sobre cualquier entorno de ejecucin compatible Su transmisin, carga y ejecucin puede ser realizada de forma remota pero aplicando unas condiciones mnimas de seguridad previamente acordadas Puede ser vericado para comprobar determinados aspectos como integridad, correccin, etc. El principal objetivo de WSbSC-RM es denir un modelo a partir del cual sea posible construir arquitecturas concretas en las que la transmisin, recepcin, carga, compilacin, ejecucin y validacin del cdigo sean servicios que puedan ser ofrecidos por sistemas potencialmente remotos y cuya poltica de seguridad sea acordada por los actores intervinientes en el proceso mediante la creacin de lazos de conanza entre ellos. En denitiva, que el cdigo no sea nicamente externamente vericable en un entorno local [36], sino tambin externamente compilable y externamente ejecutable. El modelo WSbSC-RM dene los siguientes actores: Autor: creador del cdigo y su propietario legal. Entre los servicios que puede ofrecer el autor se encuentran la mejora del cdigo proporcionando nuevas versiones del mismo, la cesin del cdigo a un tercero para su distribucin, etc. Suministrador: proporciona el cdigo a un consumidor o cliente y los distribuye con el permiso del autor. Cliente: usa el cdigo proporcionado por un suministrador. Validador: verica el cdigo conforme a una poltica de seguridad previamente acordada entre el cliente y el suministrador, proporcionando pruebas de que se trata de un cdigo seguro conforme a dicha poltica. Las comprobaciones que puede realizar el validador son muy diversas y no estn limitadas por el modelo sino que son denidas conforme a tcnicas especcas de validacin, como por ejemplo, la integridad del cdigo [37], su correccin respecto a reglas especcas tales como aserciones [45], inclusin de pruebas genricas anexionadas al cdigo (por ejemplo, Proof Carrying Code [30]) , reglas de construccin de cdigo seguro a nivel de cdigo fuente (por ejemplo, WELL [19]), reglas de vericacin de cdigo compilado [31, 45], etc.

13

Generador: a partir del cdigo obtiene otro cdigo mediante transformacin (compilacin) funcionalmente equivalente y que es compatible con el entorno de ejecucin proporcionado por el procesador. En general, entre los servicios ofrecidos por un generador, se encuentran: optimizacin de cdigo para un entorno de ejecucin determinado, generacin de cdigo con caractersticas especiales (por ej. preparado para su vericacin por el validador [31]), etc. Procesador: posee un entorno de ejecucin en el que ejecuta el cdigo proporcionado y devuelve el resultado de dicha ejecucin. Un entorno de ejecucin podr ser virtual (por ejemplo, Java Virtual Machine, JVM) o fsico (por ejemplo, una matriz de microprocesadores). Alguno de los servicios que el procesador puede ofrecer son: ejecucin de pruebas de validacin asociadas al cdigo [30], servicios especiales tales como mquinas virtuales que facilitan la validacin del cdigo [14], etc. Uno de los aspectos diferenciales del modelo es que admite diferentes escenarios que van desde la interaccin mediante servicios web entre los actores (potencialmente remotos) hasta la misma interaccin realizada en un nico sistema local en el que los actores son sistemas hardware o software. Por tanto, ntense cmo el concepto de actor es usado de forma ligeramente diferente en SOA-RM, WSA y WSbSC-RM: SOA-RM: los proveedores y consumidores de servicios son personas u organizaciones que ofrecen o usan unas capacidades por medio de un servicio. WSA: el concepto es similar (tambin son personas u organizaciones), pero se aade el concepto de Agente como el software que realiza las acciones del servicio en nombre de un determinado actor. WSbSC-RM: entendemos que la denicin de actor que ms se adecua al modelo es la segunda acepcin (ver 2.4), puesto que las arquitecturas concretas que se derivan del modelo pueden dar lugar a que alguna de las entidades que ofrecen un determinado servicio no sea una persona u organizacin sino un sistema hardware o software. En la Figura 4 se muestra un escenario con las interacciones entre cada uno de los actores en un caso genrico. Las interacciones entre los actores implican los siguientes pasos (1) El autor crea el cdigo y lo enva a un suministrador para su distribucin. (2) Un cliente localiza a un suministrador y le solicita el cdigo que satisface sus necesidades. (3) El suministrador suministra el cdigo solicitado al cliente como respuesta a su peticin. (4) El cliente pide al validador la vericacin del cdigo conforme a la poltica que tenga establecida el cliente. (5) El validador entrega el resultado de la validacin. (6) Si el cdigo suministrado no ha sido compilado para la arquitectura en la que va a ser procesado, el cliente solicita al compilador su generacin (y eventualmente, su optimizacin para esa arquitectura). (7) El generador devuelve el cdigo compilado al cliente. (8) Eventualmente, el cliente puede solicitar al validador que compruebe si el cdigo generado es correcto conforme a la poltica establecida. (9) El validador devuelve el resultado de la validacin del cdigo compilado. (10) El cliente solicita al procesador la ejecucin 14

Figura 4: Escenario General de WSbSC-RM del cdigo indicndole el entorno de ejecucin donde quiere que sea ejecutado (en caso de que el procesador soporte ms de un entorno de ejecucin) y el lenguaje en el que el cdigo ha sido compilado. (11) El procesador devuelve el resultado del procesamiento del cdigo al cliente. Se entiende que este ujo de acciones es el genrico en el que todas tienen xito. Sin embargo, podrn darse en cada caso las excepciones correspondientes en cuyo caso el cdigo no sera ejecutado. As por ejemplo, si como resultado de la primera validacin (paso 4) el validador informa que el cdigo entregado por el suministrador no puede validarse armativamente, el cliente puede optar por indicar este evento al suministrador, el cual a su vez podra, eventualmente, solicitar al autor una correccin en el cdigo para satisfacer la prueba de validacin exigida. Otras excepciones que podran producirse son: el compilador no acepta el formato del cdigo para su transformacin al entorno de ejecucin del procesador, el cliente no localiza el cdigo adecuado conforme a su poltica y por tanto debe plantearse la eleccin de otros suministradores/autores, etc. La validaciones efectuadas por el validador son las ms crticas. El modelo se centra en el proceso, los actores y sus relaciones y deja abiertas las tcnicas de validacin o las caractersticas frente a las cuales se valida el cdigo. Como veremos ms adelante, el objetivo es denir una estructura del certicado asociado al proceso de ejecucin del cdigo, mientras que los detalles de los metadatos asociados a cada uno de los actores es dependiente de la tcnica empleada. Esto conduce de forma directa a una losofa de modelo extensible, que se ha aplicado con xito a algunos estndares cuya pretensin es ser contenedores de soluciones en lugar de enumerar un conjunto limitado de posibilidades cuya ampliacin conducira indefectiblemente a la modicacin del estndar para incluirlas. Por ejemplo, WS-Policy [41], aplicado a mensajes da como resultado WS-SecurityPolicy [28] que es un contenedor de aserciones de polticas de seguridad en un intercambio de mensajes.

15

En cualquier caso, el xito de cada uno de los pasos es determinante para continuar con el proceso. Por ejemplo, si un cdigo no es vlido no tiene sentido efectuar su compilacin y, a su vez, si el cdigo compilado no recibe la aceptacin por parte del vericador, no puede ser entregado al procesador para su ejecucin. Es responsabilidad del cliente (que es quien usa el cdigo y quien determina o difunde la poltica aplicable) aceptar o no aquellas circunstancias en las que las excepciones son subsanables a posteriori. Pero en cualquier caso, el tratamiento de estas circunstancias como requisito o no, debe estar especicado en la poltica de seguridad asociada al proceso. Por otro lado, debe aclararse que el modelo se centra en los actores, sus relaciones, conceptos y el ujo del proceso de produccin y ejecucin del cdigo. La aplicacin de tcnicas concretas para la implementacin del modelo de referencia en arquitecturas de referencia o arquitecturas concretas, puede implicar la aparicin de otros actores especcos de esas tcnicas. As por ejemplo, la aplicacin de criptografa de clave pblica para efectuar la rma de los metadatos generados por los actores, implicar la participacin de otros actores como son las Entidades certicadoras que emiten los certicados de cada uno de los actores. 2.4.3. PSC y PSC-Cert

Nuestro modelo permite identicar con claridad quin realiza cada una de las funciones bsicas en la ejecucin del cdigo. Determinar la identidad de cada uno de los actores es importante desde el punto de vista de la seguridad puesto que esto nos permitir conocer en todo momento quien (persona, organizacin o sistema) cre, proporcion, gener, valid y proces el cdigo. Ntese que aunque alguna de las funciones descritas no sea realizada mediante servicios web, sino por ejemplo un dispositivo fsico o lgico, es igualmente posible identicar el actor responsable de dicha funcin junto con un conjunto de metadatos asociados a dicha funcin. Lgicamente, en este caso el valor inicial de la identidad ser no tanto por el identicativo del actor (un dispositivo) sino por cules o con qu condiciones se dene su comportamiento. Podra decirse que sabremos quin es por cmo realiza sus acciones. Con posterioridad, la identidad (contrastada por algn medio, segn la poltica de seguridad establecida) ser un dato importante para detectar cambios en el entorno y para contrastar la historia de eventos o incidencias relacionadas con un actor concreto. Para ilustrar cmo puede conseguirse con nuestro modelo una certicacin del proceso en relacin con la identidad, volvamos al escenario descrito anteriormente. Nuestra propuesta es que en el punto (9) el cdigo est asociado a la rma del validador, la cual garantiza su integridad. El procesador puede vericar la integridad del cdigo, o incluso, como hemos indicado, su correccin con respecto a unas determinadas especicaciones, antes de la ejecucin mediante esa rma. Ms an, gracias a la identicacin y determinacin de los actores mencionada, el proceso completo puede ser chequeado si cada actor rma su accin. Como consecuencia, en cada paso se generan los correspondientes metadatos de cada una de las acciones rmados por el actor de la accin correspondiente. As 16

por ejemplo, el cdigo resultado de la compilacin realizada por el generador puede venir acompaado de metadatos rmados relacionados con la compilacin. En cualquier caso, el contenido nal de los metadatos rmados viene determinado por las polticas y/o contratos entre consumidor y proveedor ( 2.10). En el apartado 2.11.2 se aborda con ms detalle la implementacin de este tipo de certicados. De este modo, al nal del proceso podemos obtener un cdigo cualicado como seguro puesto que no slo ha sido creado (autor), suministrado (suministrador), vericado (validador) y generado (compilador) por entidades identicadas y de conanza, sino que dichas acciones vienen acompaadas por metadatos que permiten su comprobacin por un tercero fuera del crculo de conanza creado entre los actores. Denominaremos al cdigo producido de esta manera PSC (Portable Secure Code), puesto que incluye informacin que lo hace seguro y portable. As mismo distinguiremos dentro de PSC dos partes: el cdigo en s mismo potencialmente representado en diversos formatos (fuente, compilado,..) y un conjunto de informacin denominada PSC-cert (certicado de PSC) que contiene toda la certicacin necesaria (metadatos rmados) para asegurar que el cdigo es seguro 1 . P SC (C ) = C + P SC -cert(C ) (2.1) Como veremos ms adelante en una primera aplicacin del modelo ( 2.4.4), esta separacin permitir que un tercero pueda comprobar la seguridad de un cdigo sin que dicho cdigo sea revelado. A partir de WSbSC-RM pueden denirse arquitecturas concretas (que etiquetaremos como WSbSC) y que son conformes a WSbSC-RM (ver 2.9). Como puede observarse, el modelo puede en efecto dar cabida a una gran variedad de escenarios, esencialmente por las variaciones respecto a los siguientes aspectos: Los roles asumidos por cada uno de los actores. Por ejemplo, un cliente puede asumir el rol de un suministrador o un autor (cuando existe autoproduccin de cdigo). Los distintos tipos de actores implicados en el proceso. Es decir, si son personas, organizaciones o sistemas hardware o software, o una combinacin de diferentes tipos de actores en una misma arquitectura. Variaciones al ujo del proceso de creacin, produccin y ejecucin del cdigo. No obstante, debe tenerse en cuenta que para el cdigo pueda ser considerado como seguro el ujo debe incluir al menos una accin relacionada con la validacin del mismo (en el modelo general descrito, existen dos acciones de validacin, una para el cdigo fuente y otra para el cdigo compilado, pero pueden existir ms). Los distintos modos de aplicar las polticas establecidas y acordadas entre las partes.
1 Se usa el operador + con el signicado de agregacin de las distintas partes expresadas en modo textual, generalmente XML

17

Figura 5: Implementacin de Servicios mediante WSbSC En las siguientes secciones, analizaremos con ms detalle algunas de estas arquitecturas WSbSC, con el n de ilustrar la aplicacin del WSbSC-RM a determinados escenarios de inters. 2.4.4. Aplicacin de WSbSC a la Implementacin de Servicios Web

Una de las aplicaciones ms interesantes del WSbSC-RM es la implementacin de servicios web. Nuestro objetivo ser obtener una arquitectura WSbSC genrica que permita aadir un nivel de seguridad adicional centrada en el cdigo a cualquier interaccin mediante Servicios Web. Consideremos una entidad consumidora de un servicio ofrecido por una determinada entidad proveedora. Siguiendo las directrices de SOA-RM y WSA, tanto la entidad consumidora como la entidad proveedora pueden establecer de forma independiente sendas polticas de seguridad sobre cmo usar u ofrecer el servicio respectivamente. Adicionalmente ambas entidades pueden acordar una poltica para sus relaciones mediante servicios web, materializando dicho acuerdo en un contrato. Para ilustrar este escenario, supongamos que es la entidad consumidora quien establece una poltica sobre las medidas de seguridad que deben ser soportadas por los proveedores de los servicios que desea usar, entendindose que para usar un servicio elegir slo aquellos proveedores del mismo que cumplen su poltica de seguridad. Dentro de la WSA, la expresin de esta poltica de seguridad se expresa generalmente mediante un conjunto de estndares tales como WS-Policy [41], WS-PolicyAttachment [40] y WS-SecurityPolicy [28]. As por ejemplo, el consumidor puede exigir que el proveedor use WS-Security [29] como estndar para garantizar la condencialidad e integridad de los mensajes intercambiados. Nuestra propuesta es aplicar WSbSC-RM para que adems de los niveles de seguridad ya conocidos (comunicaciones, datos y mensajes) se incluya la seguridad el cdigo. Este nuevo escenario, representado en la Figura 5, sera el siguiente:

18

(I) la entidad consumidora solicita un servicio de la entidad proveedora. Su poltica de seguridad establece que dicha entidad proveedora debe soportar cdigo seguro mediante WSbSC. Si es as, comienza la interaccin enviando un mensaje con los datos de entrada necesarios para que la entidad proveedora realice el servicio. Sin embargo, antes de procesar el servicio, la entidad proveedora, si no lo ha hecho anteriormente, ejecutar la implementacin del servicio siguiendo los pasos (0 a 9 en la Figura), mediante los cuales podr obtener el PSC-cert de dicha implementacin y el resultado del proceso. (II) la entidad proveedora devuelve a la entidad consumidora el resultado del proceso junto con el PSC-cert, que ser comprobado por sta examinando si cumple los requisitos de seguridad que su poltica establece. As por ejemplo podr vericar si cada uno de los actores son entidades de conanza, cules son los mtodos de vericacin empleados por el validador del proceso, etc. Uno de los aspectos importantes de esta arquitectura es que aunque la aplicacin de WSbSC-RM permitira que la entidad consumidora y proveedora tambin intercambiasen el cdigo incluido en el PSC (facilitndose la portabilidad del cdigo), no sera necesario (ni deseable) puesto que el PSC-cert (aisladamente) permite que el consumidor pueda conar en la seguridad del cdigo sin conocer dicho cdigo, tal como SOA-RM y WSA han indicado que ocurre tpicamente ( 2.3.1). La interaccin descrita admite diversas variaciones algunas de ellas con portabilidad del cdigo pero manteniendo nuevamente la premisa de que la entidad consumidora no conozca el cdigo sino su nivel de seguridad . As por ejemplo, la entidad proveedora podra enviar al consumidor una copia del cdigo cifrada con la clave pblica del validador. Si suponemos que tanto la entidad consumidora como la proveedora confan en el validador, entonces la entidad consumidora podr solicitar la validacin del cdigo al validador. La condencialidad del cdigo est garantizada por el cifrado y la clave pblica del validador garantizar que slo ste puede descifrar el cdigo, analizarlo y evaluar su validez, segn la poltica de la entidad consumidora. Pruebas peridicas de validez y el uso alternativo y simultneo de diferentes validadores de conanza pueden incrementar an ms el nivel de seguridad exigido al cdigo.

2.5.

Modelos de intercambio de informacin con WSbSC

En la seccin anterior se ha analizado la aplicacin del modelo de referencia de WSbSC donde slo una de las entidades (tpicamente el proveedor de un servicio) obtiene el PSC-cert y el cdigo no viaja necesariamente entre proveedor y consumidor. A continuacin describiremos un tercer escenario bastante ms complejo en el que ambas partes (consumidor y proveedor) deben hacer uso de PSC-cert para que se cumplan sus respectivas polticas de seguridad. Este nuevo escenario, nos permitir extender el modelo de una forma natural y consistente hacia el concepto de objeto portable y seguro. La gura 6 muestra una visin general y permite comparar los tres escenarios bsicos de intercambio de informacin entre una entidad consumidora y proveedora. El primer caso (a) es el clsico (SOA-RM [25]): ambas entidades slo inter19

Figura 6: Modelos de intercambio de informacin basados en WSbSC-RM cambian datos (generalmente contenidos en mensajes). La entidad consumidora entrega unos datos de entrada y la proveedora devuelve eventualmente unos datos de salida o resultado. Como hemos visto, aunque internamente ambas entidades realizan un proceso y mantienen estados privados, SOA-RM establece que tambin existe un estado como efecto de la vida real compartido entre ambas. El segundo caso (b) se corresponde con el escenario bsico descrito en 2.4.4 donde generalmente el cdigo no es revelado pero se obtiene un certicado del mismo (PSC-cert) que permite hacer uso de una poltica ms completa de seguridad incluyendo el cdigo. El tercer caso, cuyo detalle describiremos en los apartados siguientes, muestra el escenario ms genrico en el que se comparte proceso, se intercambia cdigo y estado y se obtienen certicados de ambos (cdigo, y cdigo + estado). En denitiva, nuestro objetivo ser extender WSbSC-RM para su aplicacin en objetos [26]. Como referencia, y para centrar el problema, partimos de los siguientes conceptos OO: Objeto : entidad que tiene un estado que slo puede ser accedido o modicado por las operaciones y servicios asociados con l. Estado : conjunto de valores de los atributos de un objeto en un momento dado. Mtodos : conjunto de las nicas operaciones autorizadas para acceder o modicar el estado de un objeto. Un objeto es algo ms que una combinacin de estado y mtodos. Segn la teora clsica de orientacin a objetos hay dos aspectos que merecen ser resaltados: 20

1. El concepto de objeto conlleva la no separacin entre sus atributos y los mtodos que los manejan. La existencia de un atributo no tiene sentido si no se reere a un objeto. De la misma forma, un mtodo de un objeto en s mismo no tiene sentido si no es como parte del objeto al que pertenece. 2. Los cambios de estado slo pueden ser producidos por la ejecucin de los mtodos del objeto. Se dice que un objeto encapsula su estado y sus mtodos. Como veremos ms adelante, lo anterior no es bice para que tanto estado como mtodos puedan ser representados de forma independiente o para que, por ej. puedan realizarse clasicaciones de objetos o rplicas de objetos dando lugar a que un mismo mtodo pueda serlo de dos objetos diferentes o un estado pueda ser transformado a distintas representaciones normalizadas. Para realizar estas clasicaciones, clsicamente se han utilizado dos conceptos: Clase : Permite denir un contenedor para objetos que tienen la misma estructura y cuyos mtodos son los mismos. En denitiva, una clase permite compartir la estructura del estado y el cdigo de los mtodos de todos los objetos creados a partir de la misma. Adems, las clases pueden heredar estructura y cdigo de otras clases mediante un mecanismo conocido como herencia. Prototipo : El concepto es similar, aunque con el importante matiz de que los objetos se crean mediante rplica de un protopipo que contiene ranuras (slots) que pueden ser atributos o mtodos. La principal diferencia con respecto al enfoque de clases es que en este tipo de soluciones el objeto no necesariamente cambia sus mtodos cuando son modicados los mtodos del objeto a partir del cual fue clonado, aunque esto podra ser posible con determinados mecanismos (como el de delegacin [24]). Para nuestro estudio nos centraremos nicamente en el concepto de objeto como encapsulacin de estado y mtodos. No obstante, los conceptos de clase y prototipo debern ser tenidos en cuenta en una posterior implementacin del modelo, entendindose que ambos conceptos son aplicables en funcin del contexto. As por ejemplo, en principio, un prototipo parece ms adecuado en mbitos no centralizados (relaciones distribuidas entre iguales), mientras que por el contrario el mantenimiento de clases parece ms indicado en mbitos centralizados donde una organizacin controla y supervisa de manera asimtrica la denicin de clases de objetos. En denitiva, sin perjuicio de la necesaria vinculacin entre estado y mtodos, tanto uno como otros pueden ser analizados de manera independiente con el n de que objetos con caractersticas y/o comportamiento similares puedan ser clasicados y reutilizados. Como veremos ms adelante, desde nuestro modelo, independientemente de los distintos modos para realizar y reutilizar tal vinculacin (clases, herencia, clonacin, delegacin), el punto ms importante es que el estado tiene asociados un conjunto de mtodos permitidos y el resto de operaciones no incluidas en dicho conjunto de mtodos tienen prohibido el acceso o modicacin del estado. En los apartados siguientes, analizaremos cmo puede obtenerse un nivel de

21

Figura 7: Objetos seguros y portables con WSbS* seguridad sobre un objeto (entendido tal como lo hemos denido) desde la perspectiva de WSbSC-RM.

2.6.

WSbSS: Estado seguro basado en Servicios Web

En el tercer caso (c) de la Figura 6 puede verse la interaccin bsica entre dos entidades usando objetos en comparacin con los casos (a) y (b). La entidad consumidora solicita un servicio de la entidad proveedora y cmo la informacin de entrada proporciona uno (o varios) objetos de entrada. La entidad proveedora realiza el servicio interactuando internamente con los objetos de entrada (mediante sus mtodos), obtiene un resultado que eventualmente tambin puede ser un objeto y lo devuelve a la entidad consumidora. Como puede deducirse, en este escenario, que se representa en mayor detalle en la Figura 7, ambas entidades intercambian adems de datos, cdigo pues los objetos de entrada y de salida tiene asociados unos mtodos implementados mediante cdigo y ambos viajan entre consumidor y proveedor. La aplicacin de WSbSC-RM permitir garantizar la seguridad de este cdigo portable. De una manera anloga, en esta situacin es necesario extender el concepto de PSC-cert para su aplicacin en objetos. En este caso los requisitos de seguridad son ms complejos puesto que el consumidor y el proveedor quieren asegurarse no slo de que la implementacin del servicio es segura (como en el caso (b) de la Figura 6) sino tambin que las interacciones entre los objetos de entrada y la implementacin del servicio son seguras. Para describir este caso con mayor profundidad, veamos un ejemplo. La entidad consumidora A solicita un servicio de la entidad proveedora B enviando junto con su solicitud un objeto de entrada O1 con un estado S1 y dos mtodos M1 y M2 conforme a la poltica establecida por B. En primer lugar, puesto que los cdigos de M1 y M2 van a ser recibidos por el entorno de ejecucin de B, tendremos que A, si no lo ha hecho previamente, 22

deber obtener el PSC de ambos siguiendo el modelo de WSbSC descrito en 2.4.2: P SC (M1 ) = C (M1 ) + P SC -cert(M1 ) P SC (M2 ) = C (M2 ) + P SC -cert(M2 ) (2.2) (2.3)

B recibe los cdigos de M1 y M2 mediante P SC (M1 ) y P SC (M2 ). De esta forma, y siguiendo igualmente las polticas y/o contratos que habrn de establecer o acordar previamente A y B, B admitir la entrada de este cdigo en su entorno puesto que lleva asociado un certicado de seguridad representado mediante PSC cert(M1 ) y P SC cert(M2 ). 2.6.1. PSS y PSS-cert

En este punto, A y B podran acordar que el estado (portable) tenga un nivel de seguridad equivalente al que tiene el cdigo. Introduciremos, de forma anloga a como fue estudiado para el cdigo ( 2.4.2), el concepto de Estado portable y seguro (PSS). En este caso, el concepto central es el estado ( 2.5) pero con las caractersticas siguientes: Puede ser portable Puede ser transformado para obtener una representacin en un formato diferente sin que el signicado de la informacin que representa se vea afectado. Su transmisin, carga y transformacin puede ser realizada de forma remota pero aplicando unas condiciones mnimas de seguridad previamente acordadas Puede ser vericado para comprobar determinados aspectos como integridad, correccin, etc. En denitiva, al igual que el cdigo puede ser externamente suministrado, compilado y validado, el estado podr ser externamente suministrado, transformado y vericado. En este caso, distinguimos los siguientes actores: Propietario: es el dueo de la informacin representada por el estado. Para entender mejor este concepto, consideremos por ejemplo el objeto Agenda cuyo estado es el conjunto de datos de contacto de una determinada persona, el cual slo puede ser accedido mediante sus mtodos (por ejemplo, aadir, borrar o modicar una cita). En este caso, el propietario de esos datos (el estado de la Agenda en un momento dado) es dicha persona. Entre los servicios que puede ofrecer se encuentra la cesin a un suministrador. Suministrador: opcionalmente, el propietario puede delegar en este actor la accin de ceder el estado a un tercero para su distribucin o uso.

23

Convertidor: opcionalmente, puede ser necesaria la conversin del estado desde un formato a otro formato, sin que el signicado de la informacin cambie, de manera anloga a como el cdigo compilado es equivalente al cdigo fuente. Entre los servicios ofrecidos por el convertidor o transformador del estado se encuentran: optimizacin (en tamao por ejemplo), generacin de formato con caractersticas especiales, etc. Validador: verica el estado conforme a unas reglas de validacin determinadas (por ejemplo, segn reglas de integridad de la informacin). A diferencia de lo estudiado hasta ahora, el estado es un dato y por tanto, en principio podra parecer innecesario aadir un nivel ms de seguridad, puesto como ya observamos, la seguridad de los datos (y ms concretamente su empaquetamiento mediante de mensajes) han sido tratados profusamente por los diferentes estndares de seguridad en servicios web. No obstante, en el caso concreto de un estado (asociado a unos mtodos) la aplicacin de la dualidad dato-programa al caso del estado es interesante porque permite modelar el estado de la misma forma que se modela el cdigo. Por otro lado, ya hemos aclarado que aunque estado y mtodos son inseparables en el sentido de que slo los mtodos permitidos permiten el acceso y modicacin del estado, eso no es bice para que la seguridad del estado sea tratada de forma independiente. As por ejemplo, de la misma forma que puede ser comprobada la integridad, la correccin y la consistencia de un determinado cdigo, lo mismo puede hacerse para el estado. El anlisis de la integridad del estado, independiente del anlisis de la integridad del cdigo es muy til para detectar el comportamiento incorrecto de los mtodos que acceden y modican dicho estado. Debe recalcarse que, a diferencia de las tcnicas de integridad de cdigo (por ej. invariantes), o estado (reglas de integridad de datos) este anlisis de integridad de cdigo y estado, aunque podr basarse en tcnicas anlogas, ser externo al objeto en s y est asociado al entorno en el que se ejecuta. Esto nos lleva a armar que el inters de aplicar el mismo modelo a ambas partes (estado y cdigo) no slo se deriva de los benecios obtenidos para cada una de ellas sino tambin de los benecios de las deducciones obtenidas como consecuencia de relacionar cdigo y estado. Otro ejemplo de las relaciones entre ambos son las consecuencias derivadas de la obtencin de los distintos formatos que el compilador por un lado y convertidor por otro efectan sobre cdigo y estado respectivamente. As, al igual que un cdigo compilado debe tener el mismo comportamiento y debe ser equivalente al cdigo fuente, un dato representado con un lenguaje de alto nivel como XML (anlogo a los lenguajes de programacin de alto nivel con una gramtica legible por su cercana a la gramtica del lenguaje natural) tambin debe ser equivalente a un dato transformado (compilado) en un formato de ms bajo nivel. Aunque deber ser objeto de un anlisis posterior ms exhaustivo, se entiende que aqu las relaciones entre los diferentes formatos y transformaciones de cdigo y estado tambin ayudan a entender mejor los aspectos de seguridad asociados y de ah su inters en nuestro modelo. Observar que las transformaciones de formato son realizadas por actores externos al cdigo y al estado y, si no se tienen en cuenta dichas transformaciones, cualquier anomala puede escapar del conocimiento de los autores y propietarios de cdigo y estado. Dicho de otro 24

Cdigo Autor Suministrador Compilador Validador

Estado Propietario Suministrador Convertidor Validador

Cuadro 1: Dualidad Cdigo/Estado entre actores modo, un cambio de formato realizado por el entorno de ejecucin del objeto no es un mtodo de ese objeto y por tanto aunque se vigile la encapsulacin de mtodos-estado, un ataque a la integridad del estado (o el cdigo) transformado por el entorno de ejecucin podra quedar fuera del estudio de la seguridad si no se aplica el modelo propuesto (ej. debe ser posible detectar si un cdigo malicioso modica directamente el archivo o la memoria donde se almacena un estado transformado o un cdigo compilado). De lo anterior se deduce que la complejidad del modelo es mayor por las posibles relaciones entre los actores que intervienen en el estado y en el cdigo. Por ejemplo, no todas las representaciones o conversiones del estado pueden ser compatibles con las transformaciones (compilaciones) del cdigo. Como veremos ms adelante, deber existir un nuevo actor que se ocupe de validar la relaciones entre cdigo y estado.

2.6.2.

Dualidad Cdigo-Estado

A modo de resumen, en la Tabla 1 se muestra la dualidad entre cdigo y estado (dato). Como ocurre en WSbSC-RM estos actores pueden ser locales o remotos. Al modelo de referencia de la arquitectura equivalente que permite el intercambio seguro de estado la denominaremos WSbSS-RM (Web Services based Secure State). Consecuentemente, obtendremos un estado cualicado como portable y seguro (PSS) que tiene un propietario, es suministrado (suministrador), transformado (convertidor) y vericado (validador) por entidades identicadas y de conanza, las cuales pueden generar metadatos con los que construir un certicado de PSS denominado PSS-cert, siendo: P SS (S ) = S + P SS -cert(S ) (2.4)

Nuevamente, esta separacin permitir que un tercero pueda comprobar la seguridad de un estado sin que dicho estado tenga que ser revelado a un tercero. Siguiendo con la interaccin en el escenario de la Figura 7, la entidad A obtendr, si no lo ha hecho anteriormente, el PSS(S), el cual indicar y permitir a B asegurarse de que dicho estado junto con sus mtodos son seguros segn el enfoque WSbSC y WSbSS.

2.7.
2.7.1.

Objetos seguros basados en Servicios Web


Aproximacin a PSO y PSO-cert

En este apartado realizaremos una primera aproximacin a una arquitectura de objetos seguros basados en Servicios Web.La aplicacin de WSbSC y WSbSS 25

conduce de una forma consistente a unas primeras deniciones de objeto seguro y portable (PSO) y certicado de objeto seguro y portable (PSO-cert):
n

O=S+
i=1

Mi

(2.5) (2.6) (2.7) (2.8)

P SO(O) = O + P SO-cert(O)
n

P SO(O) = P SS (S ) +
i=1

P SC (Mi )
n

P SO-cert(O) = P SS -cert(S ) +
i=1

P SC -cert(Mi )

Siendo O un objeto genrico con estado S y n mtodos. En nuestro ejemplo: P SO-cert(O1 ) = P SS -cert(S1 ) + P SC -cert(M1 ) + P SC -cert(M2 ). (2.9)

Del mismo modo, tal como se indic en en 2.4.4 para un escenario WSbSC, A y B utilizarn PSO-certs si as est establecido en respectivas polticas o en contratos de seguridad y consecuentemente ambas entidades confan en los actores que intervienen en la obtencin de los PSC-cert, PSS-cert y PSO-cert. Una vez que B recibe P SO(O1 ) tiene tanto el estado, cdigo de las operaciones M1 y M2 , as como los certicados de estos elementos. Se entiende que el objetivo nal es que tanto A como B puedan tener conanza entre s: A porque no puede permitir que los mtodos M1 y M2 sean ejecutados en un entorno que no sea de conanza (puesto que en ese caso podra comprometerse el objeto en s) y B porque tampoco puede permitir que se ejecuten en su entorno de ejecucin operaciones que puedan suponer un riesgo al ser ejecutadas. Por esa razn, adems del P SO cert(O1 ) enviado de A a B, B tendr que obtener un PSO-cert correspondiente a su entorno de ejecucin. Aqu se pueden encontrar diversos casos, que en cualquier caso pueden ser modelados usando PSO-certs. Por ejemplo, si B comparte los actores que han intervenido en la obtencin por parte de A del P SO cert(O1 ), en ese caso el P SO cert(O1 ) en el entorno de B es formalmente idntico al de A. En el otro extremo, B puede tener diferente suministrador, compilador, procesador y vericador y por tanto, deber obtener un nuevo PSO-cert de un objeto equivalente a O1 , que denominaremos O1 , pero cuyo cdigo compilado, vericado, suministrado y procesado es diferente del que se obtendra en el entorno de A. Tambin hay casos intermedios, tales como por ejemplo que el entorno de B sea compatible con el cdigo compilado por el compilador en A, en cuyo caso no sera necesaria transformacin alguna por parte de B. En este punto, B, a travs de la implementacin del servicio puede hacer uso del objeto O1 y ejecutar sus mtodos con el nivel de seguridad que indique P SO cert(O1 ). Como consecuencia, B podra alterar tanto su propio estado (accedido y/o modicado por la implementacin del servicio) como el estado del objeto O1 . Por tanto, A y B comparten estado (tal como establece SOA-RM) y proceso de una forma segura. 26

Es interesante resaltar que la identicacin de los actores en cada lado y los PS*-cert obtenidos ofrecen garantas en una gran variedad de situaciones. As por ejemplo, supongamos que para la interaccin entre la implementacin de servicio y el objeto O1 , y por cuestiones de rendimiento, B necesita transformar el estado de O1 en un estado equivalente pero que es ms ptimo para una interaccin que habitualmente ocurre entre A y B, como por ejemplo el acceso secuencial a una lista de elementos. En ese caso S1 debera estar formateado mediante una estructura que fuese ptima para el acceso secuencial. B al estado formateado por el convertidor de B, generalmenSi denominamos S1 te los mtodos M1 y M2 proporcionados por A pueden no ser adecuados para acceder a dicho estado (no es habitual que la implementacin de un mtodo pueda trabajar con distintas representaciones del estado). En ese caso, A y B podran acordar que el autor de B realice versiones especcas de M1 y M2 que B B llamaremos M1 y M2 que sern suministradas, compiladas, vericadas y nalmente ejecutadas en el entorno de ejecucin de B por sus actores de conanza. Es decir, en realidad B trabaja con una realizacin de O1 equivalente en proceso B y estado a la proporcionada por A y que llamaremos O1 y que podr residir en A el entorno de ejecucin de B con permiso de A. B calculara el P SO cert(O1 ), como prueba de que el proceso de conversin/compilacin, tanto de proceso como de estado ha sido realizado con las garantas establecidas en la poltica de seguridad aceptada por ambos. A B B B Una vez que B usa O1 a travs de sus mtodos M1 y M2 , O1 podr alcanzar B un nuevo estado S 1 . Para la devolucin del resultado de B a A, B deber reaB lizar el proceso inverso, es decir, convertir S 1 a la representacin original que llamaremos S 1 y devolver O 1 a A, junto con su respectivo PSO-cert. Este ltimo caso ilustra un escenario que permite aplicar el modelo a mbitos donde se necesita la interaccin con objetos en entornos de ejecucin heterogneos y en los que los vericadores correspondientes en ambas partes debern, en funcin de las polticas establecidas, realizar funciones de validacin sobre la equivalencia del cdigo y la representacin del estado en cada uno de estos diversos entornos de ejecucin. En el otro extremo se encuentra el escenario donde tanto A como B tienen entornos de ejecucin idnticos y las principales funciones de los PSO-certs sern las de garantizar que las condiciones de ejecucin de los objetos en cada entorno no se ven modicadas por ataques o alteraciones que puedan cambiar esa identidad de entornos. Finalmente y para completar el proceso, adems de los certicados de objetos obtenidos por A y B, la entidad B deber obtener el PSC-cert de la implementacin del servicio, de la misma forma que fue descrito en 2.4.4. A modo de resumen, en la Tabla 2, se muestran los PS*-cert generados en el escenario de la Figura 7.

2.8.

Acceso legal al estado. WSbSO-RM

Como indicamos en 2.5, un objeto es algo ms que una combinacin de estado y mtodos. Aunque los PSO-certs descritos hasta el momento (ecuaciones (2.5) a (2.9)) ofrecen un nivel de seguridad superior, es necesario introducir

27

Cert
P SO cert(O1 )

Quin lo obtiene
A (Consumidor)

A quin va dirigido
B(Proveedor)

Para qu se usa
Ofrece garantas a B de que la ejecucin de los mtodos del objeto O1 son seguros Ofrece garantas a A de que el objeto resultante cuyo nuevo estado ha sido obtenido en B es seguro Ofrece garantas a A de que la implementacin del servicio proporacionada por B es segura

P SO cert(O

B 1 )

B (Proveedor)

A (Consumidor)

PSC-cert(ServicioB )

B (Proveedor)

A (Consumidor)

Cuadro 2: Resumen de PS*-cert generados (escenario Figura 7 un nivel ms de seguridad con el n de asegurarse de que existen sucientes garantas de que el estado de un objeto slo es accedido slo por sus mtodos (o versiones transformadas de los mismos) independientemente del entorno de ejecucin en el que se encuentre. Volviendo al escenario de la Figura 7 puede observarse un nuevo actor validador en el mbito no de estado o mtodos sino del objeto en su conjnto. La principal funcin de ese validador es certicar que el estado S no ha sido accedido o modicado por mtodos distintos a M1 y M2 , aunque como fue apuntado en 2.6.1 podr realizar otras acciones relacionadas con la consistencia entre el par estado-cdigo. Mientras que la seguridad del cdigo y el estado por separado puede ser alcanzada de un modo aceptable en general, utilizando tcnicas criptogrcas de claves simtricas y asimtricas, as como diversas soluciones relacionadas con cdigo mvil y agentes mviles, la seguridad de acceso al estado es un campo menos estudiado y de una complejidad algo ms elevada. Algunas referencias sobre esta materia pueden ser encontradas en [11, 12]. Puede observarse que la autorizacin para acceder o modicar el estado por parte de los mtodos, conlleva en algunos casos no slo una validacin de su integridad (ya certicada por el validador del estado mediante PSS-cert) sino tambin la ocultacin del estado de tal manera que slo pueda ser revelado si se produce la ejecucin de una de las operaciones (cualquiera de ellas) y la entidad proveedora en su conjunto tiene autorizacin para su ejecucin. La necesidad de al menos dos claves de descifrado para obtener el estado (al menos una poseda por una operacin y otra poseda por el proveedor) sugiere la utilizacin de tcnicas criptogrcas basadas en la propuesta de Shamir conocida como Secret Sharing [38]. Independientemente de la tcnica utilizada para validar que la integridad cdigo-estado, podemos denir nalmente PSO-cert como:
n

P SO-cert(O) = P SS -cert(S ) +
i=1

P SC -cert(Mi ) + P SM S -cert(O) (2.10)

Siendo PSMS-cert (Portable Secure Method-State certicate) la representacin de los metadatos generados por el validador de la integridad entre estado 28

y mtodos. De manera similar, llamaremos WSbSO a las arquitecturas donde se usan los enfoques WSbSC y WSbSS descritos.

2.9.

Directrices para la conformidad con WSbS*

Una vez descrito el modelo, cabe preguntarse si es posible determinar la conformidad de una determinada arquitectura al mismo. Tal como indica SOA-RM respecto a su conformidad, la conformidad de una arquitectura concreta con los modelos descritos no es una tarea fcilmente automatizable dado que existe una gran diversidad de posibilidades de aplicacin segn las implementaciones concretas que se elan en cada caso. No obstante, desde un punto de vista conceptual y sin perjuicio de que para caso concretos podra automatizarse la vericacin de la conformidad, pueden distinguirse un conjunto de requisitos bsicos de conformidad aplicables a cada uno de los niveles de WSbS* (WSbSC, WSbSS y WSbSO). Diremos que una arquitectura es conforme a WSbS* si se cumplen las siguientes condiciones: 1. Debe ser conforme a SOA-RM ([25], lneas 759-778) 2. Deben poder identicarse alguno de los conceptos que amplan SOA-RM descritos en 2.3.1 3. Debe ser posible identicar a todos los actores tal como han sido denidos respectivamente en WSbSC, WSbSS y WSbSO. 4. Deben estar denidos todos los servicios ofrecidos por cada uno de los actores, identicando aquellos que se proporcionan mediante servicios web. Como mnimo, el suministrador del cdigo debera ofrecer los servicios mediante servicios web. 5. Debe existir una descripcin concreta de los metadatos asociados a las funciones de cada uno de los actores. Esta descripcin conformar la estructura de los respectivos PSC-certs, PSS-certs y PSO-certs. 6. Debe ser posible la identicacin de las polticas y/o contratos con relacin a la denicin y uso de los PS*-certs.

2.10.

Modelo de seguridad de WSbS*

SOA-RM que sirve como punto de partida de nuestro estudio, no incluye un modelo de seguridad genrico que permita denir diferentes enfoques de seguridad en las arquitecturas SOA. La seguridad sigue siendo una cuestin abierta en entornos SOA, objeto de investigacin [10, 21, 33] Por otro lado WSA s aborda el tema de la seguridad en una arquitectura de servicios web aunque tal como admite en su introduccin, no existen especicaciones ampliamente aceptadas sobre seguridad en servicios web. El enfoque de la seguridad segn WSA se centra especialmente en la seguridad de mensajes, las amenazas ms habituales a nivel de mensajes, los mecanismos ms habituales de seguridad (autenticacin, autorizacin, integridad, etc.) as como una serie de consideraciones diversas (identidades, polticas de conanza, interacciones 29

extremo a extremo, etc.). Las descripciones son genricas e incluso incompletas (por ejemplo, la relacin entre privacidad y servicios web es explcitamente excluida del estudio)[2]. Con posterioridad a WSA se han realizado propuestas sobre arquitecturas de seguridad en Servicios web [18], sin embargo, en la mayora de los casos el foco de atencin se ha puesto en el mensaje o en el dato. Aunque los diferentes enfoques de seguridad extremo a extremo para Servicios web suponen un avance respecto al tradicional mtodo para garantizar la seguridad entre dos puntos (generalmente mediante SSL), no es suciente. Nuestra propuesta para un modelo de seguridad, consistente con uno de los objetivos de WSbS*, es que el modelo de seguridad abarque tanto procesos como datos. Como veremos en 2.11.1 nuestro modelo de seguridad puede ser fcilmente implementado haciendo uso de estndares de servicios web. Veremos que la combinacin de estndares y un adecuado modelo de seguridad mejorar la seguridad en la arquitectura SOA. Con el objetivo de un desarrollo posterior ms exhaustivo del modelo, en este apartado se describir un estudio preliminar de los aspectos bsicos que debe contener un enfoque integral de seguridad basado en WSbS*. 2.10.1. Caractersticas del modelo de seguridad

Las principales caractersticas de nuestro modelo son: 1. Es aplicable a la arquitectura orientada a servicios y a WSbS* 2. Permite abordar la seguridad extremo a extremo no slo de datos y mensajes sino tambin del cdigo. No obstante, es compatible con estos modelos de seguridad puesto que permite aadir grados adicionales de seguridad adems de los habituales centrados en el mensaje o en el dato. 3. Puede ser implementado utilizando la tecnologa de servicios web 4. Se fundamenta en los requisitos bsicos de seguridad ampliamente aceptados 5. Es extensible, es decir, puede ser mejorado con la introduccin de nuevos conceptos 6. Se basa en conceptos aplicables a la mayora de los escenarios reales Nuestro enfoque no propone una solucin especca a un problema de seguridad concreto relacionado con servicios web sino que dene una infraestructura de seguridad genrica aplicable a una interaccin entre un consumidor y un proveedor de un servicio, sobre la cual pueden establecerse polticas concretas. Los conceptos bsicos son los siguientes: Niveles de seguridad: se reere a los sujetos a los que se aplica la seguridad (datos, cdigo, etc.) Modos de seguridad: son las caractersticas de seguridad aplicables en cada nivel 30

Mecanismos de seguridad: tcnicas especcas que permiten alcanzar una determinada seguridad Grados de seguridad: mtricas para evaluar la seguridad alcanzada La combinacin de cada uno de estos conceptos aplicados a cada escenario concreto permitir medir el grado total de seguridad de una interaccin en un entorno SOA. En los siguientes apartados se describen estos conceptos en detalle: 2.10.2. Niveles de Seguridad

Se distinguen los siguientes niveles: 1. Canal: es el medio sobre el cual se transmite la informacin que intercambian el consumidor y el proveedor del servicio. 2. Mensaje : es la unidad bsica de informacin enviada o recibida en una interaccin mediante servicios web. 3. Dato: los datos que procesa un determinado cdigo son portables y se garantiza la seguridad de extremo a extremo. Es el modelo generalmente aceptado en una arquitectura SOA realizada mediante servicios web. 4. Cdigo: es el cdigo como dato. El cdigo podr ser tratado como un dato ms y por tanto, l mismo o una certicacin del mismo, podra viajar entre dos extremos de una forma segura, 5. Proceso: el cdigo como fuente de un proceso. Este nivel de seguridad aborda la problemtica de un proceso en un determinado entorno de ejecucin, desde sus dos puntos de vista bsicos: proceso able en un entorno no conable y proceso no able en un entorno able. 6. Objeto: el cdigo como modo de acceso (mtodo) a un estado. Aborda la problemtica de seguridad asociada no al cdigo o al estado por separado sino a la garanta de que el estado slo es accedido o modicado por sus mtodos y por tanto est prohibido su acceso o modicacin directa por parte de otros procesos. Aunque podran aplicarse cada uno de estos niveles de forma independiente y no exclusiva, tal como ocurre con la mayora de las propuestas de seguridad en Servicios Web, el mayor grado de seguridad se alcanzar mediante su aplicacin progresiva. As por ejemplo, aunque es posible que en un entorno se aplique el nivel 3 y no el nivel 1 o 2, se entiende que un entorno de nivel 3 incluye los niveles 1 y 2. Para que un sistema sea seguro debe alcanzar al menos un nivel de seguridad.

2.10.3.

Modos de seguridad

Los modos de seguridad hacen referencia a la mayora de los aspectos de seguridad clsicos [13]:

31

1. Identicacin-autenticacin: debe proporcionarse algn medio de identicacin y autenticacin (comprobacin de que la identidad mediante alguno de los medios clsicos: algo que se conoce, se tiene o se es). Ntese que no se consideran identicacin y autenticacin por separado puesto que se considera que la identicacin por s sola no es segura si no va acompaada por la autenticacin. Tngase en cuenta que la identicacin cuando est referida a personas no necesariamente es incompatible con la privacidad puesto que existen mecanismos que permiten la identicacin sin revelar la identidad. 2. Integridad: debe proporcionarse algn medio para garantizar que no ha habido alteracin en el sujeto al que se le aplica la seguridad. 3. Condencialidad: se evita que el contenido o identidad sea revelado a terceros que no son de conanza. 4. No repudio: est relacionado con la identidad. En algunas situaciones no slo debe proporcionarse Identicacin-autenticacin sino que tambin debe poder demostrarse de forma fehaciente que una determinada actuacin por parte del sujeto no es posible que haya sido realizada por otro. En general, el no repudio requiere la intervencin de un tercero de conanza (por ejemplo, una entidad de certicacin aceptada por las partes) para que sea efectivo. 5. Autorizacin: debe asegurarse el control del acceso al sujeto protegido de tal forma que, en general, slo pueda realizar las acciones autorizadas. 6. Auditora: debe existir algn mecanismo para comprobar qu interacciones ha habido con el sujeto objeto de la seguridad. 7. Fiabilidad (o correccin): est relacionado con la correccin respecto a unas reglas determinadas. As por ejemplo, si el sujeto es el cdigo la abilidad implica que la ejecucin del cdigo no provoca consecuencias no deseables. A veces se confunde abilidad con los otros modos de seguridad: un cdigo puede ser inseguro no slo porque un atacante lo haya manipulado (integridad) sino tambin porque fue escrito incorrectamente por su autor y por tanto no realiza la funcin a la que estaba destinado. 8. Trazabilidad: permite identicar a los actores y la informacin relativa a las acciones que han realizado para alcanzar algn otro modo de seguridad. Este modo est directamente relacionado con nuestra propuesta de arquitectura WSbS*. La lista anterior no es completa y por tanto, otros modos de seguridad pueden ser aadidos. Sin embargo, para que un sistema sea seguro deber aplicar al menos un modo de seguridad, permitindose la combinacin de diferentes modos. Los modos de seguridad se aplican de manera independiente a cada uno de los niveles y en cada uno de ellos ser diferente el sujeto sobre el cul estn referidos. Por ejemplo, en el Nivel 1 el modo Integridad est referido a la integridad de datos.

32

2.10.4.

Mecanismos de seguridad

Los mecanismos de seguridad hacen posible alcanzar un nivel de seguridad con unos determinados modos de seguridad aplicables. La relacin entre modos y mecanismos es de varios a varios, es decir, un mecanismo puede proporcionar medios para alcanzar ms de un modo de seguridad (por ejemplo, la rma electrnica permite identidad-autenticacin, integridad y no repudio), y por otro lado, un modo de seguridad puede ser alcanzado mediante ms de un mecanismo.

2.10.5.

Sujetos de seguridad

Como hemos visto, en un entorno SOA pueden distinguirse tres tipos de sujetos a los que potencialmente puede aplicarse la seguridad: Recursos: son entidades concretas tales como servicios, mensajes, datos, etc. Actores: tal como han sido denidos en 2 Contextos: conjunto de elementos, actores, infraestructuras, etc. (Esta denicin incluye el concepto de Contexto de ejecucin, referido a una interaccin de servicios [25] ln. 720-722) El modelo est aplicado en primer lugar sobre el contexto en el que se usa un servicio y el recurso principal asociado es el servicio. En segundo lugar aparecen los niveles de seguridad denidos que se corresponden con los recursos principales que intervienen en una interaccin entre un consumidor y un proveedor para el uso de un servicio. Esta primera clasicacin en niveles permite tener una visin general del grado de seguridad alcanzado en los recursos principales. Ntese que cada uno de estos niveles se reere a sujetos de seguridad que a su vez puede estar compuesto por diversos elementos de manera jerrquica. Por ejemplo, un mensaje, segn los estndares de Servicios Web est compuesto por una cabecera y un cuerpo. Los modos de seguridad aplicables a cada nivel se reeren a ste en todos los elementos que lo forman. En tercer lugar tenemos a los actores que interactuan con cada uno de los recursos (o con los elementos de los que estn compuestos). Por ejemplo, los actores del servicio son consumidor y proveedor. En cada uno de los niveles de seguridad denidos (canal, mensaje, etc.) intervienen diferentes actores que tambin son sujetos de seguridad, es decir, sobre los cules pueden aplicarse modos y mecanismos de seguridad. 2.10.6. Grados de seguridad

Un grado de seguridad es una mtrica que permite medir de forma relativa la seguridad alcanzada conforme a diferentes criterios, as como comparar dos o ms sistemas para evaluar cul de ellos obtiene la mayor seguridad con respecto a esos criterios comunes. Los grados de seguridad estn relacionados con los sujetos sobre los cuales se aplica la seguridad.Como hemos indicado en el apartado 2.10.5, los sujetos pueden ser a su vez clasicados en otros sujetos. Cuando un modo de seguridad

33

se aplica slo a una parte del nivel se entiende que ese grado de seguridad (an siendo lgicamente superior a la ausencia de ese modo) est incompleto. La asignacin de un peso por cada aplicacin de un modo en los sujetos y sus partes o clasicaciones permitir obtener un valor cuantitativo (grado) que indicar una mayor o menor seguridad en el conjunto de una manera jerrquica La medida de la seguridad est relacionada con el concepto general de Calidad de Servicio (QoS) puesto que se trata de un elemento ms en la medicin del nivel de calidad en una interaccin mediante servicios web. Nuestra propuesta ampla y mejora la medicin de la seguridad como un parmetro de la calidad, ya que la mayor parte de las propuestas se centran esencialmente en el mensaje [32, 22].

2.11.

Implementacin del modelo

La aplicacin de los diferentes estndares sobre Servicios Web permiten implementar el modelo para una gran variedad de escenarios. Aunque un desarrollo ms detallado de la implementacin podr ser realizado posteriormente con la aplicacin de nuestro enfoque a un caso real, en este apartado vamos a realizar una descripcin preliminar del proceso de implementacin y los estndares bsicos aplicables (en [6, 17] pueden encontrarse las ltimas versiones de los estndares desarrollados por las dos principales organizaciones de estandarizacin en Servicios Web y SOA: W3C y OASIS). Aunque nuestro principal foco de atencin ser la implementacin de PS*-certs y la descripcin del modelo de seguridad que han sido planteado en 2.10, a continuacin describiremos brevemente la implementacin en el caso particular de WSbSC, entendiendo que WSbSS y WSbSO se realizan de manera anloga. Volviendo al escenario de implementacin de un servicio web mediante PSC representado en la gura 5, veamos las consideraciones que han de tenerse en cuenta para su implementacin: 1. Cada uno de los actores (Autor, Suministrador, Validador, Generador y Procesador) debern ser registrados en un repositorio UDDI 2. Los actores registran sus servicios bsicos en un repositorio UDDI. Esto permite la localizacin de cada uno de ellos por parte del resto de los intervinientes. Por ejemplo, para el caso de un cliente que soporte el nivel 4 de seguridad, los servicios bsicos que ofrecen cada uno de los actores sern: Autor: requestForCodeTransference : solicitud de derechos para distribuir el cdigo Suministrador: sendCodeForTransference : envo de un cdigo por parte de un autor para su distribucin requestCode : solicitud de un cdigo por parte de un cliente Validador: validateCode : peticin de validacin de un cdigo 34

Generador: compileCode Procesador: processCode Y el cliente por su parte deber ofrecer al menos los siguientes servicios: Cliente: sendValidatedCode : recepcin de un cdigo de un autor para su distribucin sendCompiledCode : envo de cdigo compilado por parte de un generador sendResults : envo de los resultados del proceso del cdigo Como ya hemos indicado estos servicios pueden ser, en un caso general, ofrecidos por los actores mediante servicios web, o a nivel local mediante cualquier otra tecnologa, pero de conformidad con WSbSC el PSC-cert resultante deber reejar la identicacin de estos actores y los metadatos que se generan por cada una de sus acciones. 3. El consumidor establece mediante WS-Policy [41] y WS-PolicyAttachment [40] la poltica de seguridad que desea aplicar, basndose en las directrices del apartado 2.9 y tal como se indica en 2.11.1. Obsrvese que tal como se indica en [40], la poltica de seguridad puede estar incluida en el mismo directorio UDDI en el que est registrado el consumidor. 4. El consumidor obtiene la descripcin WSDL del servicio (probablemente de un repositorio UDDI) y hace la solicitud mediante mensajes SOAP con o sin WS-Security [29] (segn la poltica establecida por el proveedor). 5. El proveedor al recibir la peticin del servicio interroga al repositorio UDDI sobre la poltica de seguridad establecida por el consumidor del servicio o bien obtiene dicha informacin directamente en el mensaje. En dicha poltica de seguridad expresada mediante WS-Policy, tiene conocimiento del requerimiento de nivel 4 de seguridad que implica la utilizacin de WSbSC. 6. El proveedor, si no lo ha hecho anteriormente, obtiene el PSC-cert de la implementacin del servicio (el detalle es descrito en 2.11.1). En funcin de la poltica establecida por el cliente podr aplicar distintos estndares de seguridad a cada uno de los recursos protegidos indicados por la poltica de seguridad establecida por el consumidor y, en su caso, por su propia poltica. 7. El proveedor enva un mensaje mediante SOAP o WS-Security [23] al consumidor con el resultado del servicio y el PSC-cert de su implementacin. Si el consumidor no recibe el PSC-cert, podr, en funcin de su poltica, rechazar el resultado de la realizacin del servicio.

35

2.11.1.

Implementacin de las poltica de seguridad

El estudio preliminar del modelo de seguridad asociado a WSbS* ha puesto de maniesto las distintas caractersticas de seguridad de deben tenerse en cuenta en cualquier solucin basada en WSbS*. La implementacin de estas caractersticas en forma de requerimientos de seguridad permitir, tal como ya se ha apuntado, a que los intervinientes puedan denir polticas de seguridad completas que exan por ejemplo, la utilizacin de PS*-certs como medio para reforzar la seguridad a distintos niveles. Para la implementacin de la descripcin de esas polticas se propone la utilizacin de estndares de seguridad ampliamente utilizados en soluciones SOA y ms concretamente en aquellas basadas en Servicios Web. A falta de un desarrollo futuro ms detallado, los principales estndares propuestos son los siguientes: WS-Policy [41]: permite denir aserciones genricas. WS-PolicyAttachment [40] dene diferentes formas de asociar polticas basadas en WS-Policy WS-SecurityPolicy [28]: aplicacin de WS-Policy y WS-PolicyAttachment a WS-Security [23] SAML [7]: permite la utilizacin de credenciales de identicacin, autenticacin y atributos de seguridad XACML [27]: facilita la denicin de reglas de autorizacin sobre cualquier tipo de recurso 2.11.2. Implementacin de PS*-certs

En este apartado analizamos con ms detalle la implementacin de PS*certs. La denicin de cada PS*-cert depender de las polticas y/o contratos de las entidades consumidora y proveedora. Sin embargo, podemos distinguir una estructura comn de PSC-cert, PSS-cert y MS-cert, conforme a cada una de sus deniciones. En la gura 8 se muestra la estructura general de un PSO. Cada uno de los metadatos generados por cada uno de los actores tiene la misma estructura (T_Metadata). Fmonos en el caso concreto de los metadatos generados por el Autor de un PSC. Como puede observarse en la gura 9, estos metadatos (AuthoredCode) estn compuestos por las siguientes partes: ActorIdentity: contiene informacin sobre el actor (Autor en el ejemplo). Admite una referencia a una entidad UDDI o una referencia a un actor ya denido (por ej. si un mismo actor est realizando varios roles). CredentialsReference: contiene informacin sobre las credenciales otorgadas al actor. Por ej. un suministrador tiene las credenciales otorgadas por el autor para que pueda suministrar el cdigo en su nombre. La implementacin tpica ser una referencia a un documento SAML.

36

Figura 8: Estructura general de PSO

37

Figura 9: Estructura general de un PSC-cert SubjectMetadata: la estructura de esta parte depende del tipo de actor. Se reere a los metadatos del actor relacionados con su accin. Por ej. en el caso del autor, incluye nombre del cdigo, licencia, lenguaje de programacin, resultado de su accin, etc. SubjectPolicy: es una referencia a la descripcin de la poltica asociada a ese conjunto de metadatos. Por ejemplo, podra incluir una referencia a aserciones WS-Policy. ds:Signature: es un elemento XML-Signature (enveloped) que contiene la rma de todos los metadatos del actor. Tpicamente ser una rma digital basada en certicados X509. El resto de los metadatos de un PSC-cert (SuppliedCode, CompiledCode, VeriedCode) generados por los otros actores (Suministrador, Compilador y Vericador) tienen la misma estructura, aunque como se ha indicado la parte SubjectMetadata a su vez tendr una estructura diferente segn el actor. Lo anterior se aplica de manera anloga a pss-cert y psms-cert. En el apndice se incluye un listado completo de un ejemplo de codicacin en XML de un PSO.

2.12.

Consideraciones sobre el rendimiento

El modelo descrito ha denido un escenario genrico en el que tal como hemos indicado pueden producirse diversas variaciones que conducen a diversos 38

escenarios, los cuales an siendo conformes al modelo, son mucho ms simples. En el caso general, las representaciones de los correspondientes PS* (PSC, PSS, PSO) y PS*-certs pueden ser extensas y complejas introduciendo una sobrecarga signicativa y por tanto, derivando en un menor rendimiento 2.11. Aunque un estudio emprico sobre el rendimiento podr ser realizado junto con la implementacin de casos reales, las siguientes consideraciones deben tenerse en cuenta en cualquier anlisis sobre rendimiento respecto al modelo: No es necesaria la obtencin de PS*-certs en cada interaccin entre consumidores y proveedores. Debe entenderse que la implementacin del modelo deber establecer mecanismos para que ambos proveedor y consumidor puedan detectar los cambios que hagan necesaria la obtencin de nuevos PS*-certs. As por ejemplo, sera necesaria en el caso de nuevas versiones del cdigo, cambios en la identidad de los actores, etc. Por otro lado, mediante mecanismos como las sesiones puede conseguirse que la obtencin de esa informacin slo sea necesaria al principio de una interaccin. A este respecto, existen algunos estndares como que abordan este aspecto [9, 8]. Los roles de los diferentes actores del modelo pueden ser realizados por la misma entidad, simplicndose por tanto la generacin de los metadatos contenidos en los PS*-certs. Por ejemplo, una misma entidad de certicacin puede realizar el rol de validador de cdigo, estado, y objeto, tanto en la parte de la entidad proveedora como consumidora (asumiendo que ambas entidades consideran de conanza a dicha entidad de certicacin). El modelo establece que todos los actores deben ser identicados a los distintos niveles (cdigo, estado y objeto), salvo aquellos indicados como opcionales. Sin embargo, en determinados escenarios y determinados actor no tiene por qu ser una organizacin o persona ofreciendo sus servicios mediante Servicios Web ( 2), sino que puede ser un componente hardware [16]. En este caso, la representacin de PSC-certs podr tomar una forma ms compacta. En los ltimos aos se han realizado esfuerzos para conseguir un mayor rendimiento en el uso de servicios web (un interesante estudio puede ser encontrado en [39])

3.

Conclusiones y trabajo futuro

El presente trabajo ha tenido como objeto el desarrollo de una nueva propuesta para abordar un tema complejo como es la seguridad del cdigo en el contexto de la arquitectura orientada a servicios y ms especcamente desde el enfoque de la arquitectura de servicios web. El concepto central de partida para todo el desarrollo es la premisa de que En el contexto de una arquitectura SOA slo ser posible alcanzar un nivel adecuado de seguridad si los mecanismos de proteccin tratan no slo los datos sino tambin el cdigo que los gestiona

39

La primera conclusin es que es posible compatibilizar un modelo genrico como es la arquitectura de referencia SOA con los conceptos que aparecen en el estudio de la seguridad del cdigo, puesto que el cdigo tambin es un elemento importante (aunque olvidado) en una arquitectura orientada a servicios. El modelo obtenido aunque parte de conceptos aparentemente simples y conocidos (como le ocurre al propio modelo SOA y el de Servicios web), conduce en su desarrollo al modelado de situaciones ms complejas. En este trabajo se presenta la aplicacin del modelo a un caso de gran inters como es la implementacin de un servicio en un escenario genrico. Posteriormente, el modelo concebido inicialmente para el cdigo se ampla y extiende para tratar con la misma losofa (y teniendo en mente la conocida dualidad dato-programa), el problema de la seguridad del estado y de un objeto entendido como la encapsulacin de cdigo y estado. Ser necesario profundizar un poco ms en el modelo completando algunos aspectos que sin duda aparecern en la aplicacin a casos reales. Por otro lado, ser muy interesante particularizar y aplicar el modelo a soluciones que fueron propuestas en el pasado (algunas de ellas muy desarrolladas como PCC), en el contexto del cdigo mvil y los agentes mviles. Esto podr poner a prueba, an ms, la consistencia y la generalidad del modelo. Dicho estudio es costoso en tiempo dada la gran cantidad de propuestas y la complejidad de las mismas, no obstante podr aadir valor al modelo y, sobre todo, puede permitir la aplicacin con un enfoque ms actual de algunas tcnicas de algn modo relegadas (e incluso olvidadas), a mbitos muy especcos. Como segunda conclusin, podemos armar que uno de los puntos centrales de la propuesta ha sido la introduccin del concepto de PS*-cert y en el presente trabajo se ha realizado una primera aproximacin a su implementacin mediante XML, basndose en conocidos estndares como UDDI, SAML, WS-Policy o XML-Signature. La introduccin de otros estndares para tratar diversos aspectos que indudablemente aparecern en la aplicacin de un caso real, es un trabajo futuro que por s mismo supone una gran complejidad. Relacionado con esto ltimo, la complejidad de los estndares, su compatibilidad, el establecimiento de modos bsicos de interoperabilidad entre los mismos (proles) as como la propia naturaleza dinmica y evolutiva de los estndares (continuamente aparecen nuevas versiones y nuevos estndares) inuye en que el resultado nal de los lenguajes propuestos ya puede adivinarse complejo. En la aplicacin prctica del modelo nos encontraremos con el problema del rendimiento, crucial si se desea que dicha aplicacin prctica sea adems aplicable a casos reales. Siendo un objetivo central del trabajo futuro precisamente esa aplicacin efectiva a casos reales. En este sentido, se ha realizado una primera aproximacin al problema del rendimiento con algunas indicaciones de cmo puede mejorarse en casos reales. No obstante, esto es un problema general que afecta a cualquier solucin basada en SOA (y ms concretamente en servicios web) para el cual ya estn apareciendo propuestas de optimizacin, al igual que ocurri en su da con la propuesta de mquinas virtuales Java, cuyo rendimiento evolucion de forma positiva en el tiempo hasta convertirse en una tecnologa muy extendida, sin problemas de rendimiento en su aplicacin real. En tercer lugar, otro aspecto abordado en este trabajo que requerir un desa40

rrollo futuro es la efectiva denicin de un modelo de seguridad asociado a la propuesta, cuyas bases han sido descritas en una de las secciones. La principal aportacin de esta primera aproximacin al modelo de seguridad es la distincin entre distintos niveles de proteccin incluyendo el nivel de datos, cdigo, proceso y la combinacin de ambos (objeto). Sobre este ltimo nivel, y tal como se ha indicado, se propone el estudio de una solucin basada en tcnicas de Secret Sharing. La mayor dicultad a la hora de desarrollar la propuesta ha sido el hecho de que el tema abordado es al mismo tiempo novedoso (por el enfoque de cdigo sobre SOA) y tambin relacionado con muchos trabajos anteriores (por su carcter de modelo de referencia). Podra armarse como ltima conclusin que el estudio de modelos de referencia, en apariencia sencillos, puede conllevar, al contrario de lo que podra suponerse, mayor complejidad que el desarrollo de soluciones a problemas muy concretos. El presente trabajo por tanto, puede sentar las bases de otros trabajos ms especcos, aunque no por ello menos interesantes.

41

Bibliografa
[1] D. Booth, H. Haas, and A. Brown. Web services glossary. Technical report, Technical report, World Wide Web Consortium (W3C), 2004. http://www. w3. org/TR/ws-gloss, February 2004. [2] David Booth, Hugo Haas, Francis Mccabe, Eric Newcomer, Michael Champion, Chris Ferris, and David Orchard. Web services architecture, w3c working group note 11 february 2004. World Wide Web Consortium, article available from: http://www. w3. org/TR/ws-arch, 2004. [3] R. R. Brooks. Mobile code paradigms and security issues. IEEE Internet Computing, 8(3):5459, 2004. [4] Antonio Carzaniga, Gian P. Picco, and Giovanni Vigna. Designing distributed applications with mobile code paradigms. In ICSE 97: Proceedings of the 19th international conference on Software engineering, pages 2232, New York, NY, USA, 1997. ACM Press. [5] Joris Claessens, Bart Preneel, and Joos Vandewalle. (how) can mobile agents do secure electronic transactions on untrusted hosts? a survey of the security issues and the current solutions. ACM Trans. Inter. Tech., 3(1):2848, February 2003. [6] Oasis Committees. Summary of oasis standards and other approved work, http://www.oasis-open.org/specs/. [7] Conor, John, Hal, Michael, Rebekah, Rick, Thomas, Irving, Paula, Maryann, Michael, Tony, Nick, Scott, Rl, Peter, Je, Frederick, John Kemp, Paul Madsen, Steve Anderson, Prateek Mishra, John Linn, Rob Philpott, Jahan Moreh, Anne Anderson, Eve Maler, Ron Monzillo, and Greg Whitehead. Security assertion markup language (saml) v2. 0, March 2005. [8] Doug Davis, Anish Karmarkar, Gilbert Pilz, Steve Winkler, and Umit Yalcinalp. Web services reliable messaging (ws-1 reliablemessaging) version 1.1. Technical report, OASIS, April 2007. [9] A. Ecm. Application session services. Technical report, ECMA, June 2004. [10] J. Epstein, S. Matsumoto, and G. Mcgraw. Software security and soa: danger, will robinson! Security & Privacy Magazine, IEEE, 4(1):8083, 2006.

42

[11] W. M. Farmer, J. D. Guttman, and V. Swarup. Security for mobile agents: Authentication and state appraisal. Proceedings of the 4th European Symposium on Research in Computer Security (ESORICS96), pages 118130, 1996. [12] William M. Farmer, Joshua D. Guttman, and Vipin Swarup. Security for mobile agents: Issues and requirements. NIST, 1996. [13] D. Firesmith. Specifying reusable security requirements. Journal of Object Technology, 3(1):6175, 2004. [14] Michael Franz, Deepak Chandra, Andreas Gal, Vivek Haldar, Fermin Reig, and Ning Wang. A portable virtual machine target for proof-carrying code. In IVME 03: Proceedings of the 2003 workshop on Interpreters, virtual machines and emulators, pages 2431, New York, NY, USA, 2003. ACM Press. [15] Lawrence A. Gordon, Martin P. Loeb, William Lucyshyn, and Robert Richardson. Computer crime and security survey 2006, 2006. [16] Trusted C. Group. Tcg specication architecture overview v1.2. Technical report, Trusted Computing Group, April 2004. [17] W3c Groups. Summary of w3c technical reports and publications, http://www.w3.org/tr/. [18] Carlos Gutierrez, Eduardo Fernandez-Medina, and Mario Piattini. Web services enterprise security architecture: a case study. In SWS 05: Proceedings of the 2005 workshop on Secure web services, pages 1019, New York, NY, USA, 2005. ACM Press. [19] Vivek Haldar, Christian H. Stork, and Michael Franz. The source is the proof. In NSPW 02: Proceedings of the 2002 workshop on New security paradigms, pages 6973, New York, NY, USA, 2002. ACM Press. [20] Fritz Hohl. A model of attacks of malicious hosts against mobile agents. Object Oriented Technology - ECOOP98 Workshop Reader: ECOOP98 Workshops, Demos, and Posters, Brussels, Belgium, July 1998. Proceedings, pages 593593, 1998. [21] Indrakshi. An aspect-based approach to modeling access control concerns. Journal of Information and Software Tecnology, 46(9), 2004. [22] Eunju Kim and Youngkon Lee. Oasis web services quality model tc. Technical report, OASIS, September 2005. [23] Kelvin Lawrence and Chris Kaler. Web services security: Soap message security 1.1 (ws-security 2004), February 2006. [24] Henry Lieberman. Using prototypical objects to implement shared behavior in object-oriented systems. In OOPLSA 86: Conference proceedings on Object-oriented programming systems, languages and applications, pages 214223, New York, NY, USA, 1986. ACM Press.

43

[25] C. M. Mackenzie, K. Laskey, F. Mccabe, P. F. Brown, and R. Metz. Reference model for service oriented architecture v 1.0. Technical report, OASIS, 2006. [26] B. Meyer. Reusability: The case for object-oriented design. Software, IEEE, 4(2):5064, 1987. [27] Tim Moses. extensible access control markup language tc v2.0 (xacml), February 2005. [28] Anthony Nadalin, Marc Goodner, Martin Gudgin, Abbie Barbir, and Hans Granqvist. Ws-securitypolicy 1.2, March 2007. [29] Anthony Nadalin, Chris Kaler, Ronald Monzillo, and Phillip Hallam-Baker. Web services security: Soap message security 1.1 (ws-security 2004). OASIS Standard, 200401, February 2006. [30] George C. Necula. Proof-carrying code. In POPL 97: Proceedings of the 24th ACM SIGPLAN-SIGACT symposium on Principles of programming languages, pages 106119, New York, NY, USA, 1997. ACM Press. [31] George C. Necula and Peter Lee. The design and implementation of a certifying compiler. SIGPLAN Not., 33(5):333344, May 1998. [32] Pierluigi Plebani. Quality of web services, September 2006. [33] D. G. Rosado, C. Gutierrez, E. Fernandez-Medina, and M. Piattini. A study of security architectural patterns. Availability, Reliability and Security, 2006. ARES 2006. The First International Conference on, pages 8 pp.+, 2006. [34] A. D. Rubin and D. E. Geer. Mobile code security. IEEE Internet Computing, 2(6):3034, 1998. [35] Jarogniew Rykowski and Wojciech Cellary. Virtual web services: application of software agents to personalization of web services. In ICEC 04: Proceedings of the 6th international conference on Electronic commerce, pages 409418, New York, NY, USA, 2004. ACM Press. [36] Arvind Seshadri, Mark Luk, Adrian Perrig, Leendert van Doorn, and Pradeep Khosla. Externally veriable code execution. Commun. ACM, 49(9):4549, September 2006. [37] Arvind Seshadri, Mark Luk, Elaine Shi, Adrian Perrig, Leendert van Doorn, and Pradeep Khosla. Pioneer: verifying code integrity and enforcing untampered code execution on legacy systems. In SOSP 05: Proceedings of the twentieth ACM symposium on Operating systems principles, volume 39, pages 116, New York, NY, USA, December 2005. ACM Press. [38] Adi Shamir. How to share a secret. Commun. ACM, 22(11):612613, November 1979. [39] Kezhe Tang, Shiping Chen, D. Levy, J. Zic, and B. Yan. A performance evaluation of web services security. Enterprise Distributed Object Computing Conference, 2006. EDOC 06. 10th IEEE International, pages 6774, 2006. 44

[40] Asir S. Vedamuthu, David Orchard, Frederick Hirsch, Maryann Hondo, Prasad Yendluri, Touc Boubez, and Umit Yalcinalp. Web services policy 1.5 - attachment. World Wide Web Consortium, article available from: http://www.w3.org/TR/ws-policy-attach, 2007. [41] Asir S. Vedamuthu, David Orchard, Frederick Hirsch, Maryann Hondo, Prasad Yendluri, Touc Boubez, and Umit Yalcinalp. Web services policy 1.5 - framework. World Wide Web Consortium, article available from: http://www.w3.org/TR/ws-policy, March 2007. [42] John Viega and Jeremy Epstein. Why applying standards to web services is not enough. IEEE Security and Privacy, 4(4):2531, July 2006. [43] Lynn Wheeler. Security taxonomy and glossary. Technical report, Garlic, 2007. [44] Michael E. Whitman. Enemy at the gate: threats to information security. Commun. ACM, 46(8):9195, August 2003. [45] Zhichen Xu, Barton P. Miller, and Thomas Reps. Safety checking of machine code. In PLDI 00: Proceedings of the ACM SIGPLAN 2000 conference on Programming language design and implementation, volume 35, pages 7082, New York, NY, USA, May 2000. ACM Press. [46] J. Zachary. Protecting mobile code in the wild. IEEE Internet Computing, 7(2):7882, 2003.

45

Apndice A

Glosario
Servicio : Mecanismo que permite el acceso a un conjunto de una o ms aptitudes, en el que el acceso se proporciona por una interfaz normalizada y cuyo uso es ejercido consistentemente mediante restricciones y polticas especicadas en la denicin del servicio. Actor : Persona u organizacin que puede ser propietaria de agentes y que ofrece o solicita un servicio Entidad proveedora de un servicio : Actor que ofrece un servicio Entidad consumidora de un servicio : Actor que desea utilizar un servicio ofrecido por un proveedor Agente de un servicio : Es una pieza concreta de software o hardware que enva y recibe mensajes y que acta en nombre de una persona y organizacin. Existen dos tipos bsicos de agentes de servicios: Agente proveedor : agente que est autorizado y es capaz de llevar a cabo las acciones asociadas con un servicio en nombre de su propietario que es la entidad proveedora del mismo. Agente consumidor : agente que est autorizado y es capaz de llevar a cabo las acciones asociadas con un servicio en nombre de su propietario que es la entidad consumidora del mismo. Mensaje : Es la unidad bsica de los datos enviados por un agente de servicio a otro agente en el contexto de Servicios Web Poltica : (en el contexto de servicio): Una poltica representa las restricciones en el comportamiento de un agente cuando realiza acciones o acceso a recursos. Una poltica tambin puede estar referida al comportamiento de actores, en este caso las restricciones no se traducen de manera exclusiva en restricciones sobre el comportamiento permitido de los agentes que actan en nombre de tales actores. Una poltica debera estar representada por cada uno de los siguientes aspectos: Aserciones : sentencias que describen una determinada restriccin asociada a una poltica. 46

Propietario de poltica : es el actor que dene y posee una determinada poltica. Dominio : es un conjunto identicado de agentes y/o actores que aceptan y por lo tanto estn sujetos a las restricciones de una poltica. Vigilante de poltica : actor responsable del cumplimiento de la poltica. Normalmente es el propietario. Guarda de poltica : mecanismo que asegura (fuerza) el cumplimiento de una poltica. Descripcin de poltica : es la representacin en un lenguaje formal y/o no formal, de una poltica. Modelo de referencia : conjunto mnimo de conceptos, axiomas y relaciones dentro de un determinado dominio y que es independiente de estndares especcos, tecnologas, implementaciones y otros detalles concretos. Este conjunto forma un modelo abstracto que permite comprender las principales relaciones entre las entidades de un entorno y el desarrollo de arquitecturas especcas que usen estndares o especicaciones aplicados a este entorno. Arquitectura : De referencia : estructura que ofrece una solucin abstracta a un problema en un determinado dominio. Concreta : implementacin especca de una solucin basada en arquitecturas de referencia, patrones y requisitos adicionales, incluidos los que vienen determinados por el entorno tecnolgico. Contrato (en el contexto de servicio): Un contrato representa un acuerdo entre dos o ms actores. Mientras que una poltica est asociada con el punto de vista de un actor individual, los contratos implican acuerdos entre varias partes. De manera anloga a una poltica, un contrato debera estar representado por cada uno de los siguientes aspectos: Clusulas : son las aserciones de un contrato. Partes : son el conjunto de actores que aceptan las clusulas del contrato. Vigilante de contrato : actor responsable del cumplimiento de un contrato. Puede ser una autoridad externa a las partes. Guarda de contrato : mecanismo que asegura (fuerza) el cumplimiento del contrato. Descripcin de contrato : es la representacin en un lenguaje formal y/o no formal, de un contrato Principios bsicos de seguridad : Mnimo privilegio : Es el principio de seguridad fundamental: Cualquier sujeto (usuario, administrador, programa, sistema, etc) debe tener slo los privilegios que necesita para realizar las tareas que tiene asignadas.

47

Mltiples niveles de defensa : No basar toda la seguridad en un nico mecanismo. Instalar mltiples mecanismos de seguridad que acten en caso de fallo de los dems Diversidad de defensas : No slo son necesarios distintos niveles de defensa sino tambin distintas clases de defensa. Punto dbil : La seguridad de un sistema es siempre la de su elemento ms dbil. Punto de choque : Obligar al atacante a usar un canal de entrada que pueda monitorizarse y controlarse. Simplicidad : La simplicidad es un principio de seguridad por dos razones: 1) Si algo es ms fcil de comprender tambin es ms fcil de proteger. No puede protegerse algo que no se comprende. 2) La complejidad proporciona todo tipo de posibilidades para el hallazgo de puntos dbiles. No obstante, nunca debe comprometerse la seguridad por la simplicidad, un sistema debe ser tan simple como sea posible pero no ms.

48

Apndice B

Ejemplo de codicacin en XML de PS*-certs


Este apndice describe la representacin XML simplicada de PSO correspondiente al un ejemplo de objeto denominado MyPersonalPlanner (agenda para planicacin personal de tareas). Se supone que dicho objeto slo tiene dos mtodos: AddAppointment y DeleteAppointment.

Figura B.1: Ejemplo de PSO-cert Se ha supuesto tambin que la validacin en todos los niveles (PSC, PSS y PSMS) es realizada por el mismo Validador. Algunas secciones de la representacin XML (por ej. ds:Signature) han sido simplicadas para facilitar la legibilidad. No obstante, el cdigo ha sido comprobado sintcticamente (Wellformed) y gramaticalmente (Validated) conforme a su XML-Schema. La estructura general del PSO-cert est representada en la Figura B.1.

49

PSO of MyPersonalPlanner Object


1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43

<?xml version="1.0" encoding="utf-8"?> <wsbs:pso wsu:Id="pso:MyPersonalPlanner" xmlns:wsbs="..." xmlns:uddi="urn:uddi-org:api_v3" xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" xmlns:wsp="http://www.w3.org/ns/ws-policy" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="... PSO-Cert.xsd"> <wsbs:o wsu:Id="o:MyPersonalPlanner"> <wsbs:method wsu:Id="psc:MyPersonalPlanner:AddAppointment"> <wsbs:Code wsu:Id="source:MyPersonalPlanner:AddAppointment" EncodingType="Base64"> cHVibGljIGNsYXNzIENvbnZlcnRlcg0Kew0KICBwd.. </wsbs:Code> <wsbs:Code wsu:Id="compiled:MyPersonalPlanner:AddAppointment" EncodingType="Base64"> CByZXR1cm4gKGNlbHNpdXMgKiA5IC8gNSk.. </wsbs:Code> </wsbs:method> <wsbs:method wsu:Id="psc:MyPersonalPlanner:DeleteAppointment"> <wsbs:Code wsu:Id="source:MyPersonalPlanner:DeleteAppointment" EncodingType="Base64"> Ji98cfHwsHHycsYs0IdT5N7bhwpP2Vejg5BY1o9i.. </wsbs:Code> <wsbs:Code wsu:Id="compiled:MyPersonalPlanner:DeleteAppointment" EncodingType="Base64"> kOld9kI83F45HbgHugLXu80d.. </wsbs:Code> </wsbs:method> <wsbs:s wsu:Id="psc:MyPersonalPlanner:CurrentState"> <wsbs:CurrentState wsu:Id="xmllist:MyPersonalPlanner:CurrentState" EncodingType="Base64"> <PersonalPlanner> <TopIndex>3</TopIndex> <Element index="2007-10-02T09:00"> Flight to New York </Element> <Element index="2007-15-02T014:00"> Return from New York </Element> </PersonalPlanner> </wsbs:CurrentState> <wsbs:CurrentState wsu:Id="csv:MyPersonalPlanner:CurrentState" EncodingType="Base64"> CByZXR1cm4gKGNlbHNpdXMgKiA5IC8gNSk.. </wsbs:CurrentState> </wsbs:s> </wsbs:o> <wsbs:pso-cert wsu:Id="pso-cert:MyPersonalPlanner"> <wsbs:psc-cert wsu:Id="psc-cert:MyPersonalPlanner:AddAppointment">

50

44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88

<!--author metadata--> <wsbs:AuthoredCode wsu:Id="psc-cert:MyPersonalPlanner:AddAppointment:AuthoredCode"> <!--Actor identity metadata--> <wsbs:ActorIdentity wsu:Id="MyPersonalPlanner:Author"> <wsbs:AuthorReference uddi:businessKey="uddi:sf.com:sw:05a1"/> </wsbs:ActorIdentity> <!--Actor credentials--> <wsbs:CredentialsReference URI=".../saml-author-credentials"/> <!--Subject metadata--> <wsbs:SubjectMetadata URI="#source:MyPersonalPlanner:AddAppointment"> <wsbs:ProgrammingLanguage> <wsbs:Name>Java</wsbs:Name> <wsbs:Version>1.5</wsbs:Version> </wsbs:ProgrammingLanguage> <wsbs:Description> Add an appoinment to the personal planner </wsbs:Description> <wsbs:InterfaceSchema URI=".../MyPersonalPlanner.AddAppointment.xsd"/> <wsbs:Version>1.0</wsbs:Version> <wsbs:License wsbs:licenseType="GPL">....</wsbs:License> <wsbs:Result> <wsbs:ActionTime>2007-05-02T09:45:00Z</wsbs:ActionTime> <wsbs:VersionHistory> <wsbs:VersionDescription wsbs:VersionNumber="1.0"> Initial </wsbs:VersionDescription> ... </wsbs:VersionHistory> </wsbs:Result> </wsbs:SubjectMetadata> <wsbs:SubjectPolicy> <wsp:PolicyReference URI="../MyPersonalPlannerPolicy#AddAppointment:AuthoredCode" > </wsp:PolicyReference> </wsbs:SubjectPolicy> <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#"> <ds:SignedInfo> <ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/> <ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/> <ds:Reference URI="#psc-cert:MyPersonalPlanner:AddAppointment:AuthoredCode"> <ds:Transforms> <ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/> <ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/> </ds:Transforms> <ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/> <ds:DigestValue>AjPpVHwLzJS6AALuTU90oDvaUWo=</ds:DigestValue>

51

89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133

</ds:Reference> </ds:SignedInfo> <ds:SignatureValue> Lej4nb8f/gxgObOUYuo1zFEyZKnoTtdU5ew9UwdeMC+k... </ds:SignatureValue> <KeyInfo> <X509Data> <X509IssuerSerial> <X509IssuerName> OU=FNMT Clase 2 CA,O=FNMT,C=ES </X509IssuerName> <X509SerialNumber>1014886138</X509SerialNumber> </X509IssuerSerial> <X509Certicate> MIIFRTCCBK6gAwIBAgIEPH3u+jANBgkqhkiG9w0BAQUF.... </X509Certicate> </X509Data> </KeyInfo> </ds:Signature> </wsbs:AuthoredCode> <!--metadata added by supplier--> <wsbs:SuppliedCode wsu:Id="psc-cert:MyPersonalPlanner:AddAppointment:SuppliedCode"> <!--Actor identity metadata--> <wsbs:ActorIdentity wsu:Id="MyPersonalPlanner:Supplier"> <wsbs:CompilerReference uddi:businessKey="uddi:sf.com:sw:05a2"/> </wsbs:ActorIdentity> <!--Actor credentials--> <wsbs:CredentialsReference URI=".../saml-supplier-credentials"/> <!--Subject metadata--> <wsbs:SubjectMetadata URI="#source:MyPersonalPlanner:AddAppointment"> <wsbs:Result> <wsbs:ActionTime>2007-05-02T09:45:00Z</wsbs:ActionTime> <wsbs:Correct>true</wsbs:Correct> </wsbs:Result> </wsbs:SubjectMetadata> <wsbs:SubjectPolicy> <wsp:PolicyReference URI="../MyPersonalPlannerPolicy#AddAppointment:SuppliedCode" > </wsp:PolicyReference> </wsbs:SubjectPolicy> <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#"> .... <ds:Reference URI="#psc-cert:MyPersonalPlanner:AddAppointment:SuppliedCode">.. </ds:Reference> ....

52

134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178

</ds:Signature> </wsbs:SuppliedCode> <!--metadata added by compiler--> <wsbs:CompiledCode wsu:Id="psc-cert:MyPersonalPlanner:AddAppointment:CompiledCode"> <!--Actor identity metadata--> <wsbs:ActorIdentity wsu:Id="MyPersonalPlanner:Compiler"> <wsbs:CompilerReference uddi:businessKey="uddi:sf.com:sw:05a2"/> </wsbs:ActorIdentity> <!--Actor credentials--> <wsbs:CredentialsReference URI=".../saml-compiler-credentials"/> <!--Subject metadata--> <wsbs:SubjectMetadata URI="#source:MyPersonalPlanner:AddAppointment"> <wsbs:targetLanguage> <wsbs:Name>bytecode</wsbs:Name> <wsbs:Version>45.3</wsbs:Version> </wsbs:targetLanguage> <wsbs:compilerEnvironment wsbs:VersionNumber="5.0"> JDK </wsbs:compilerEnvironment> <wsbs:Result> <wsbs:ActionTime>2007-05-02T09:45:00Z</wsbs:ActionTime> <wsbs:Correct>true</wsbs:Correct> <wsbs:SubjectResult URI="#compiled:MyPersonalPlanner:AddAppointment"/> </wsbs:Result> </wsbs:SubjectMetadata> <wsbs:SubjectPolicy> <wsp:PolicyReference URI="../MyPersonalPlannerPolicy#AddAppointment:CompiledCode" > </wsp:PolicyReference> </wsbs:SubjectPolicy> <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#"> .... <ds:Reference URI="#psc-cert:MyPersonalPlanner:AddAppointment:CompiledCode"> ..</ds:Reference> .... </ds:Signature> </wsbs:CompiledCode> <!--metadata added by verier--> <wsbs:VeriedCode wsu:Id="psc-cert:MyPersonalPlanner:AddAppointment:VeriedCode"> <!--Actor identity metadata--> <wsbs:ActorIdentity wsu:Id="MyPersonalPlanner:Verier"> <wsbs:VerierReference uddi:businessKey="uddi:sf.com:sw:05a3"/> </wsbs:ActorIdentity> <!--Actor credentials--> <wsbs:CredentialsReference URI=".../saml-verier-credentials"/>

53

179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223

<!--Subject metadata--> <wsbs:SubjectMetadata URI="#source:MyPersonalPlanner:AddAppointment"> <wsbs:VericationType>ProofDelegation</wsbs:VericationType> <wsbs:Result> <wsbs:ActionTime>2007-05-02T09:45:00Z</wsbs:ActionTime> <wsbs:Correct>true</wsbs:Correct> </wsbs:Result> </wsbs:SubjectMetadata> <wsbs:SubjectMetadata URI="#compiled:MyPersonalPlanner:AddAppointment"> <wsbs:VericationType>ProofDelegation</wsbs:VericationType> <wsbs:Result> <wsbs:ActionTime>2007-05-02T09:45:00Z</wsbs:ActionTime> <wsbs:Correct>true</wsbs:Correct> </wsbs:Result> </wsbs:SubjectMetadata> <wsbs:SubjectPolicy> <wsp:PolicyReference URI="../MyPersonalPlannerPolicy#AddAppointment:VeriedCode" > </wsp:PolicyReference> </wsbs:SubjectPolicy> <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#"> .... <ds:Reference URI="#psc-cert:MyPersonalPlanner:AddAppointment:VeriedCode"> ..</ds:Reference> .... </ds:Signature> </wsbs:VeriedCode> </wsbs:psc-cert> <wsbs:psc-cert wsu:Id="psc-cert:MyPersonalPlanner:DeleteAppointment"> <!--author metadata--> <wsbs:AuthoredCode wsu:Id="psc-cert:MyPersonalPlanner:DeleteAppointment:AuthoredCode"> <!--Actor identity metadata--> <wsbs:ActorIndentityReference URI="#MyPersonalPlanner:Author"/> <!--Actor credentials--> <wsbs:CredentialsReference URI=".../saml-author-credentials"/> <!--Subject metadata--> <wsbs:SubjectMetadata URI="#source:MyPersonalPlanner:DeleteAppointment"> <wsbs:ProgrammingLanguage> <wsbs:Name>Java</wsbs:Name> <wsbs:Version>1.5</wsbs:Version> </wsbs:ProgrammingLanguage> <wsbs:Description> Removes an appoinment from the personal planner </wsbs:Description> <wsbs:InterfaceSchema URI=".../MyPersonalPlanner.DeleteAppointment.xsd"/>

54

224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268

<wsbs:Version>1.1</wsbs:Version> <wsbs:License wsbs:licenseType="GPL">....</wsbs:License> <wsbs:Result> <wsbs:ActionTime>2007-05-02T09:45:00Z</wsbs:ActionTime> <wsbs:VersionHistory> <wsbs:VersionDescription wsbs:VersionNumber="1.0"> Initial </wsbs:VersionDescription> <wsbs:VersionDescription wsbs:VersionNumber="1.1"> Check if exists previously </wsbs:VersionDescription> </wsbs:VersionHistory> </wsbs:Result> </wsbs:SubjectMetadata> <wsbs:SubjectPolicy> <wsp:PolicyReference URI="../MyPersonalPlannerPolicy#DeleteAppointment:AuthoredCode" > </wsp:PolicyReference> </wsbs:SubjectPolicy> <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#"> .... <ds:Reference URI="#psc-cert:MyPersonalPlanner:DeleteAppointment:AuthoredCod"> ..</ds:Reference> .... </ds:Signature> </wsbs:AuthoredCode> <!--metadata added by supplier--> <wsbs:SuppliedCode wsu:Id="psc-cert:MyPersonalPlanner:DeleteAppointment:SuppliedCode"> <!--Actor identity metadata--> <wsbs:IndentityReference URI="#MyPersonalPlanner:Supplier"/> <!--Actor credentials--> <wsbs:CredentialsReference URI=".../saml-supplier-credentials"/> <!--Subject metadata--> <wsbs:SubjectMetadata URI="#source:MyPersonalPlanner:DeleteAppointment"> <wsbs:Result> <wsbs:ActionTime>2007-05-02T09:45:00Z</wsbs:ActionTime> <wsbs:Correct>true</wsbs:Correct> </wsbs:Result> </wsbs:SubjectMetadata> <wsbs:SubjectPolicy> <wsp:PolicyReference URI="../MyPersonalPlannerPolicy#DeleteAppointment:SuppliedCode" > </wsp:PolicyReference> </wsbs:SubjectPolicy> <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">

55

269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 304 305 306 307 308 309 310 311 312 313

.... <ds:Reference URI="#psc-cert:MyPersonalPlanner:DeleteAppointment:SuppliedCode"> ..</ds:Reference> .... </ds:Signature> </wsbs:SuppliedCode> <!--metadata added by compiler--> <wsbs:CompiledCode wsu:Id="psc-cert:MyPersonalPlanner:DeleteAppointment:CompiledCode"> <!--Actor identity metadata--> <wsbs:IndentityReference URI="#MyPersonalPlanner:Compiler"/> <!--Actor credentials--> <wsbs:CredentialsReference URI=".../saml-compiler-credentials"/> <!--Subject metadata--> <wsbs:SubjectMetadata URI="#source:MyPersonalPlanner:DeleteAppointment"> <wsbs:targetLanguage> <wsbs:Name>bytecode</wsbs:Name> <wsbs:Version>45.3</wsbs:Version> </wsbs:targetLanguage> <wsbs:compilerEnvironment wsbs:VersionNumber="5.0"> JDK </wsbs:compilerEnvironment> <wsbs:Result> <wsbs:ActionTime>2007-05-02T09:45:00Z</wsbs:ActionTime> <wsbs:Correct>true</wsbs:Correct> <wsbs:SubjectResult URI="#compiled:MyPersonalPlanner:DeleteAppointment"/> </wsbs:Result> </wsbs:SubjectMetadata> <wsbs:SubjectPolicy> <wsp:PolicyReference URI="../MyPersonalPlannerPolicy#DeleteAppointment:CompiledCode" > </wsp:PolicyReference> </wsbs:SubjectPolicy> <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#"> .... <ds:Reference URI="#psc-cert:MyPersonalPlanner:DeleteAppointment:CompiledCode"> ..</ds:Reference> .... </ds:Signature> </wsbs:CompiledCode> <!--metadata added by verier--> <wsbs:VeriedCode wsu:Id="psc-cert:MyPersonalPlanner:DeleteAppointment:VeriedCode"> <!--Actor identity metadata--> <wsbs:IndentityReference URI="#MyPersonalPlanner:Verier"/> <!--Actor credentials--> <wsbs:CredentialsReference URI=".../saml-verier-credentials"/>

56

314 315 316 317 318 319 320 321 322 323 324 325 326 327 328 329 330 331 332 333 334 335 336 337 338 339 340 341 342 343 344 345 346 347 348 349 350 351 352 353 354 355 356 357 358

<!--Subject metadata--> <wsbs:SubjectMetadata URI="#source:MyPersonalPlanner:DeleteAppointment"> <wsbs:VericationType>ProofDelegation</wsbs:VericationType> <wsbs:Result> <wsbs:ActionTime>2007-05-02T09:45:00Z</wsbs:ActionTime> <wsbs:Correct>true</wsbs:Correct> </wsbs:Result> </wsbs:SubjectMetadata> <wsbs:SubjectMetadata URI="#compiled:MyPersonalPlanner:DeleteAppointment"> <wsbs:VericationType>ProofDelegation</wsbs:VericationType> <wsbs:Result> <wsbs:ActionTime>2007-05-02T09:45:00Z</wsbs:ActionTime> <wsbs:Correct>true</wsbs:Correct> </wsbs:Result> </wsbs:SubjectMetadata> <wsbs:SubjectPolicy> <wsp:PolicyReference URI="../MyPersonalPlannerPolicy#DeleteAppointment:VeriedCode" > </wsp:PolicyReference> </wsbs:SubjectPolicy> <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#"> .... <ds:Reference URI="#psc-cert:MyPersonalPlanner:DeleteAppointment:VeriedCode"> ..</ds:Reference> .... </ds:Signature> </wsbs:VeriedCode> </wsbs:psc-cert> <wsbs:pss-cert wsu:Id="pss-cert:MyPersonalPlanner:CurrentState"> <!--owner metadata--> <wsbs:OwnedData wsu:Id="pss-cert:MyPersonalPlanner:CurrentState:OwnedData"> <!--Actor identity metadata--> <wsbs:ActorIndentityReference URI="#MyPersonalPlanner:Author"/> <!--Actor credentials--> <wsbs:CredentialsReference URI=".../saml-owner-credentials"/> <!--Subject metadata--> <wsbs:SubjectMetadata URI="#xmllist:MyPersonalPlanner:CurrentState"> <wsbs:DataFormat> <wsbs:Name>XML</wsbs:Name> <wsbs:Version>1.0</wsbs:Version> <wsbs:Structure URI=".../MyPersonalPlanner.state.xsd"/> </wsbs:DataFormat> <wsbs:Description> List of appoinments from the Personal Planner </wsbs:Description>

57

359 360 361 362 363 364 365 366 367 368 369 370 371 372 373 374 375 376 377 378 379 380 381 382 383 384 385 386 387 388 389 390 391 392 393 394 395 396 397 398 399 400 401 402 403

<wsbs:Version>1.0</wsbs:Version> <wsbs:License wsbs:licenseType="GPL">....</wsbs:License> <wsbs:Result> <wsbs:ActionTime>2007-05-02T09:45:00Z</wsbs:ActionTime> <wsbs:VersionHistory> <wsbs:VersionDescription wsbs:VersionNumber="1.0"> Initial </wsbs:VersionDescription> </wsbs:VersionHistory> </wsbs:Result> </wsbs:SubjectMetadata> <wsbs:SubjectPolicy> <wsp:PolicyReference URI="../MyPersonalPlannerPolicy#CurrentState:OwnedData" > </wsp:PolicyReference> </wsbs:SubjectPolicy> <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#"> .... <ds:Reference URI="#pss-cert:MyPersonalPlanner:CurrentState:OwnedData"> ..</ds:Reference> .... </ds:Signature> </wsbs:OwnedData> <!--metadata added by converter--> <wsbs:ConvertedData wsu:Id="pss-cert:MyPersonalPlanner:CurrentState:ConvertedData"> <!--Actor identity metadata--> <wsbs:IndentityReference URI="#MyPersonalPlanner:Converter"/> <!--Actor credentials--> <wsbs:CredentialsReference URI=".../saml-converter-credentials"/> <!--Subject metadata--> <wsbs:SubjectMetadata URI="#xmllist:MyPersonalPlanner:CurrentState"> <wsbs:targetFormat> <wsbs:Name>csv</wsbs:Name> <wsbs:Version>1.0</wsbs:Version> <wsbs:Structure URI="http://tools.ietf.org/html/rfc4180"/> </wsbs:targetFormat> <wsbs:ConverterEnvironment wsbs:VersionNumber="5.0"> JDK </wsbs:ConverterEnvironment> <wsbs:Result> <wsbs:ActionTime>2007-05-02T09:45:00Z</wsbs:ActionTime> <wsbs:Correct>true</wsbs:Correct> <wsbs:SubjectResult URI="#csv:MyPersonalPlanner:CurrentState"/> </wsbs:Result> </wsbs:SubjectMetadata>

58

404 405 406 407 408 409 410 411 412 413 414 415 416 417 418 419 420 421 422 423 424 425 426 427 428 429 430 431 432 433 434 435 436 437 438 439 440 441 442 443 444 445 446 447 448

<wsbs:SubjectPolicy> <wsp:PolicyReference URI="../MyPersonalPlannerPolicy#CurrentState:ConvertedData" > </wsp:PolicyReference> </wsbs:SubjectPolicy> <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#"> .... <ds:Reference URI="#pss-cert:MyPersonalPlanner:CurrentState:ConvertedData"> ..</ds:Reference> .... </ds:Signature> </wsbs:ConvertedData> <!--metadata added by state verier--> <wsbs:VeriedData wsu:Id="pss-cert:MyPersonalPlanner:CurrentState:VeriedData"> <!--Actor identity metadata--> <wsbs:IndentityReference URI="#MyPersonalPlanner:Verier"/> <!--Actor credentials--> <wsbs:CredentialsReference URI=".../saml-verier-credentials"/> <!--Subject metadata--> <wsbs:SubjectMetadata URI="#xmllist:MyPersonalPlanner:CurrentState"> <wsbs:VericationType>Integrity</wsbs:VericationType> <wsbs:Result> <wsbs:ActionTime>2007-05-02T09:45:00Z</wsbs:ActionTime> <wsbs:Correct>true</wsbs:Correct> </wsbs:Result> </wsbs:SubjectMetadata> <wsbs:SubjectMetadata URI="#csv:MyPersonalPlanner:CurrentState"> <wsbs:VericationType>Integrity</wsbs:VericationType> <wsbs:Result> <wsbs:ActionTime>2007-05-02T09:45:00Z</wsbs:ActionTime> <wsbs:Correct>true</wsbs:Correct> </wsbs:Result> </wsbs:SubjectMetadata> <wsbs:SubjectPolicy> <wsp:PolicyReference URI="../MyPersonalPlannerPolicy#CurrentState:VeriedData" > </wsp:PolicyReference> </wsbs:SubjectPolicy> <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#"> .... <ds:Reference URI="#pss-cert:MyPersonalPlanner:CurrentState:VeriedData"> ..</ds:Reference> .... </ds:Signature> </wsbs:VeriedData>

59

449 450 451 452 453 454 455 456 457 458 459 460 461 462 463 464 465 466 467 468 469 470 471 472 473 474 475 476 477 478

</wsbs:pss-cert> <wsbs:psms-cert wsu:Id="psms-cert:MyPersonalPlanner"> <wsbs:VeriedMethodData wsu:Id="psms-cert:MyPersonalPlanner:VeriedMethodData"> <!--Actor identity metadata--> <wsbs:IndentityReference URI="#MyPersonalPlanner:Verier"/> <!--Actor credentials--> <wsbs:CredentialsReference URI=".../saml-verier-credentials"/> <!--Subject metadata--> <wsbs:SubjectMetadata URI="#o:MyPersonalPlanner"> <wsbs:VericationType>StateAppraisal</wsbs:VericationType> <wsbs:Result> <wsbs:ActionTime>2007-05-02T09:45:00Z</wsbs:ActionTime> <wsbs:Correct>true</wsbs:Correct> </wsbs:Result> </wsbs:SubjectMetadata> <wsbs:SubjectPolicy> <wsp:PolicyReference URI="../MyPersonalPlannerPolicy#VeriedMethodData" > </wsp:PolicyReference> </wsbs:SubjectPolicy> <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#"> .... <ds:Reference URI="#psms-cert:MyPersonalPlanner:VeriedMethodData"> ..</ds:Reference> .... </ds:Signature> </wsbs:VeriedMethodData> </wsbs:psms-cert> </wsbs:pso-cert> </wsbs:pso>

60

A continuacin se muestra el XML-schema correspondiente a un PSO.

XML-Schema of PSO
1 2 3 4 5 6

<?xml version="1.0" encoding="UTF-8"?> <xs:schema xmlns:wsbs="..." xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" xmlns:ds="http://www.w3.org/2000/09/xmldsig#" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:wsp="http://www.w3.org/ns/ws-policy" xmlns:uddi="urn:uddi-org:api_v3" targetNamespace="..."> <xs:complexType name="T_UDDIReference"> <xs:attribute ref="uddi:businessKey" use="required"/> </xs:complexType> <xs:complexType name="T_ActorUDDIReference"> <xs:sequence> <xs:element name="UDDIReference" type="wsbs:T_UDDIReference"/> </xs:sequence> <xs:attribute ref="wsu:Id" use="required"/> </xs:complexType> <xs:complexType name="T_ActorReference"> <xs:attribute name="URI" type="xs:anyURI" use="required"/> </xs:complexType> <xs:complexType name="T_ActorIdentity"> <xs:choice> <xs:element name="ActorUDDIReference" type="wsbs:T_ActorUDDIReference"/> <xs:element name="ActorReference" type="wsbs:T_ActorReference"/> </xs:choice> </xs:complexType> <xs:complexType name="T_CredentialsReference"> <xs:attribute name="URI" type="wsbs:AT_9" use="required"/> </xs:complexType> <xs:complexType name="T_SubjectMetadata"> <xs:sequence> <xs:choice minOccurs="0"> <xs:element ref="wsbs:VericationType"/> <xs:sequence> <xs:choice> <xs:sequence> <xs:element ref="wsbs:ProgrammingLanguage"/> <xs:element ref="wsbs:Description"/> <xs:element ref="wsbs:InterfaceSchema"/> </xs:sequence> <xs:sequence> <xs:element ref="wsbs:DataFormat"/>

7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40

61

41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85

<xs:element ref="wsbs:Description"/> </xs:sequence> </xs:choice> <xs:element ref="wsbs:Version"/> <xs:element ref="wsbs:License"/> </xs:sequence> <xs:sequence> <xs:element ref="wsbs:targetLanguage"/> <xs:element ref="wsbs:compilerEnvironment"/> </xs:sequence> <xs:sequence> <xs:element ref="wsbs:targetFormat"/> <xs:element ref="wsbs:ConverterEnvironment"/> </xs:sequence> </xs:choice> <xs:element ref="wsbs:Result"/> </xs:sequence> <xs:attribute name="URI" type="wsbs:AT_5" use="required"/> </xs:complexType> <xs:complexType name="T_SubjectPolicy"> <xs:sequence> <xs:element ref="wsp:PolicyReference"/> </xs:sequence> </xs:complexType> <xs:complexType name="T_Metadata"> <xs:sequence> <xs:element name="ActorIdentity" type="wsbs:T_ActorIdentity"/> <xs:element name="CredentialsReference" type="wsbs:T_CredentialsReference"/> <xs:element name="SubjectMetadata" type="wsbs:T_SubjectMetadata" maxOccurs="unbounded"/> <xs:element name="SubjectPolicy" type="wsbs:T_SubjectPolicy"/> <xs:element ref="ds:Signature"/> </xs:sequence> <xs:attribute ref="wsu:Id" use="required"/> </xs:complexType> <xs:element name="psc-cert"> <xs:complexType> <xs:sequence> <xs:element name="AuthoredCode" type="wsbs:T_Metadata"/> <xs:element name="SuppliedCode" type="wsbs:T_Metadata"/> <xs:element name="CompiledCode" type="wsbs:T_Metadata"/> <xs:element name="VeriedCode" type="wsbs:T_Metadata"/> </xs:sequence> <xs:attribute ref="wsu:Id" use="required"/> </xs:complexType> </xs:element>

62

86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128

<xs:element name="psc"> <xs:complexType> <xs:sequence> <xs:element ref="wsbs:Code" maxOccurs="unbounded"/> </xs:sequence> <xs:attribute ref="wsu:Id" use="required"/> </xs:complexType> </xs:element> <xs:element name="o"> <xs:complexType> <xs:sequence> <xs:element ref="wsbs:psc" maxOccurs="unbounded"/> <xs:element ref="wsbs:pss"/> </xs:sequence> <xs:attribute ref="wsu:Id" use="required"/> </xs:complexType> </xs:element> <xs:element name="compilerEnvironment"> <xs:complexType> <xs:simpleContent> <xs:extension base="wsbs:T_compilerEnvironment"> <xs:attribute name="VersionNumber" type="wsbs:AT_15" use="required" form="qualied"/> </xs:extension> </xs:simpleContent> </xs:complexType> </xs:element> <xs:element name="VersionHistory"> <xs:complexType mixed="true"> <xs:sequence> <xs:element ref="wsbs:VersionDescription" maxOccurs="unbounded"/> </xs:sequence> </xs:complexType> </xs:element> <xs:element name="VersionDescription"> <xs:complexType> <xs:simpleContent> <xs:extension base="wsbs:T_VersionDescription"> <xs:attribute name="VersionNumber" type="wsbs:AT_21" use="required" form="qualied"/> </xs:extension> </xs:simpleContent> </xs:complexType> </xs:element> </xs:schema>

63

Apndice C

Publicaciones y Trabajos presentados en Congresos


El trabajo de investigacin ha producido resultados signicativos, sustanciados en dos comunicaciones en sendos congresos, uno de mbito internacional y otro nacional. Es reseable que la comunicacin presentada en el Congreso internacional ser publicada en la serie Lectures Notes in Computer Science, incluida en el Journal Citation Reports (JCR). A continuacin se recogen las referencias a los congresos y las publicaciones asociadas: 1. Comunicacin: E. Rodrguez Priego, F.J. Garca, "Securing Code in Services Oriented Architecture", que ser presentada en la International Conference on Web Engineering 2007 (ICWE07), que tendr lugar del 16 al 20 de Julio del presente ao en Como, Italia. 2. Publicacin: E. Rodrguez Priego, F.J. Garca, "Securing Code in Services Oriented Architecture", LNCS 4607, pp. 550 - 555, Springer Verlag, 2007. 3. Comunicacin: E. Rodrguez Priego, F.J. Garca, "Securing objects in Services Oriented Architecture", que ser presentada en la III Jornadas Cientco Tcnicas en Servicios Web y SOA (JSWeb 2007), que tendr lugar del 12 al 13 de Septiembre del presente ao en Zaragoza. A continuacin se incluyen los textos de ambas publicaciones.

Securing Code in Services Oriented Architecture


Emilio Rodriguez Priego and F.J. Garca
Departamento de Matemticas y Computacin Universidad de La Rioja Edificio Vives, Luis de Ulloa s/n E-26004 Logrono (La Rioja, Spain) {emilio.rodriguez, francisco.garcia}@unirioja.es

Abstract. SOA proposed security mechanisms are only centered in the data transmitted between service provider and consumer. However, its well known that the biggest threats to the integrity of the information are precisely focused not on the data directly but on the code that manages it. Our main statement is that it will only be possible to reach an acceptable level of security if the protection mechanisms cover not only the data but also the code that process these data. In this paper we present a new approach about mobile code security based on the Services Oriented Architecture Reference Model and Web Services technology. This new model allows the development of systems with end-to-end security, where all elements (code and data) are secure. Keywords: Web services security, mobile code security, Service Oriented Architecture.

1 Introduction to the Problem


Nowadays, there is a growing interest in Web Services technology and Service Oriented Architecture (SOA), whose Reference Model has been recently approved as an OASIS standard [2]. In this model, a consuming entity requests from a supplier entity, one or more services under a set of conditions (interaction, visibility, execution context, policies and contracts). At the same time, security is one of the aspects that requires more attention due to the application of this technology to environments where information exchange is made through public networks like Internet, in which there potentially exists diverse security threats. Recently different standard-based solutions have been proposed to solve the problem of secure sending and reception of messages. According to SOA, the performed action details of the supplied service are not typically visible by the consumer [1, 2]. Therefore SOA does not address the subjects related to the realization of a service, like, e.g. securing it, delegating the effective resolution of these problems to the supplier. The proposed security mechanisms of the SOA model and the technology of web services are centered in the transmitted data (message), and they put their focus on end to end integrity, confidentiality, identity and authentication. These mechanisms work well and in practice they reach the objective. However, its well known that the biggest threats to the integrity of the information are precisely focused not on the data directly but on the code that manages it [8,9].
L. Baresi, P. Fraternali, and G.-J. Houben (Eds.): ICWE 2007, LNCS 4607, pp. 550 555, 2007. Springer-Verlag Berlin Heidelberg 2007

Securing Code in Services Oriented Architecture

551

Therefore, our main statement is that it will only be possible to reach an acceptable level of security if the protection mechanisms cover not only the data but also the code that process these data. Independently of the web services development and SOA model, the security problem of mobile code and its interaction with the environment in which code is executed has been studied in the last years, particularly for the singular case of mobile agents [6]. Both SOA and mobile code have specific and common aspects of security but until now had not been treated jointly. The main contribution of this article is the proposal of a new approach to the problem of the security of mobile code, named Web Services based Secure Code (here-in-after WSbSC) that its based on SOA Reference Model and the Web Services Architecture. WSbSC allows for the improvement of security in a typical interaction between consumer and provider without forcing the participants to necessarily know the details of implementation of the services. Our model is virtually applicable to any SOA situation in which an integral model of security, involving data and code was required. However, in certain situations code visibility, integrity and/or portability are more important, because code integrity, the code in itself, the source of the code or all of these elements, take part or are exchanged as part of services provided by the supplier. Typical examples of these application environments are distributed processes, hosting or rent of processes, auditing and validation of code by certification entities, and so on. Once the problem that we want to address has been stated, the rest of the paper is organized in two main sections, each one describing its own objectives, resolution outline and methodology. In Section 2, we provide a general description of the WSbSC reference model. Section 3 presents the application of the model to a basic SOA interaction. The last section summarizes the main contribution, related work, the status of the research and indicates the future work.

2 WSbSC Reference Model


The reference model of WSbSC (here-in-after WSbSC-RM) is an abstract framework for understanding significant relationships among service entities (providers and consumers) that allows an integral (data and code) secure interaction, enabling the development of specific architectures using consistent standards or specifications. WSbSC-RM relies on SOA-RM and it adds new concepts and relationships to the modeling of data and code exchange based on services. The central concept in WSbSC-RM is the code, just as it has been defined traditionally but with some specific features: (1) the code can be portable: i.e., it can be sent from one system to another without manual intervention; (2) the code can be executed in any compatible execution environment; (3) transmission, load and execution of the code can be carried out in a safe way, applying the same basic principles of secure transmission of data (identity, integrity and confidentiality); and (4) the code can be verified in a secure manner. There have been different proposals related to code portability, validation and execution in distributed environments [4,5,7]. Most proposals are based on hardware or software techniques for execution in a local environment.

552

E.R. Priego and F.J. Garca

WSbSC-RM states that the transmission, reception, execution, load, compilation and validity of the code are services that can be offered by systems potentially remote and weakly coupled. As we see below, with WSbSC code is not only externally verifiable [3], but also externally compilable and externally executable. WSbSC-RM distinguishes the following actors: Author: it's the owner and creator of the code and its legal owner. Supplier: provides the code to a consumer and distributes it by author permission. Client: uses the code provided by a supplier. Verifier: verifies the code according to a security policy previously established. Compiler: given a code, it compiles another functional equivalent code. Processor: possesses an execution environment that executes the code.

All WSbSC-RM actors are service consumers or providers, from the point of view of SOA-RM. Besides WSbSC-RM allows the modeling (recursively) of the actions (local or remote) of a service by composing services offered by these actors and according to code-centric policies and contracts. What is a key added factor of our approach with reference to SOA, is that actors playing the role of consumers in any relationship to a provider may impose a certain security policy to regulate the service that the provider is going to perform. This policy, and here is the contribution, does not only affect the data (message) as SOA does, but also the service implementation. This policy refers to one or several security aspects (such as integrity, confidentiality, validity, and so on) and may specify a mechanism or set of mechanisms that the provider must implement to accomplish the policy. These security requirements can be used by the consumer to select the most suitable provider in each case, depending on the mechanisms the former can implement. The response to each service request will include, as well as the result, metadata about the required, and fulfilled, policy.

Author
[10] [2] [1] Graphical Notation

Processor
[11] [7]

Client
[8] [6] [9] [5]

[3] [4]

Supplier A A

A uses a service

B from B
Entity that offers and/or uses a service

Compiler

Verifier

Fig. 1. General WSbSC-RM scenario

At this point, we have not studied yet all relationships between WSbSC-RM actors like service actors, but we can illustrate these relationships by describing a general example that shows some key concepts in SOA-RM: service, interaction, policies and contracts, real world effect, etc. Fig. 1 shows this general scenario. Interactions involve the following steps: (1) An author creates the code and sends it to a supplier for distribution. (2) A client localizes and requests the code that satisfies its needs from the supplier. (3) The supplier delivers the code. (4) The client requests the verification of the code according to the client policy from a verifier. (5) The verifier delivers the validated code. (6) If code is not compiled for the architecture in which is going to be

Securing Code in Services Oriented Architecture

553

executed then the client requests its generation from a compiler. (7) The compiler returns the compiled code. (8) The client can request validity of the compiled code from the verifier. (9) The verifier returns the validated code. (10) The client requests to a processor execution of the code. (11) The processor returns the result of the process to the client. At point (9) the code is associated to the verifier's signature that guarantees its integrity. The Processor can verify code integrity, or even correctness with respect to a certain specification, before execution by means of that signature. Moreover, the overall process can be checked if each actor signs its action. As a result, each step generates metadata signed by the service provider, as well as its signature; e.g., the result code of the compiler can include metadata related to that compilation. This means that at the end of the process we can get a code qualified as "secure" since it's created (author), provided (supplier), validated (verifier) and generated (compiler) by trusted identified entities. This code, that we'll name Portable Secure Code (PSC) is formally "portable" and "secure". We have that PSC = Code + PSC-cert (cert stands from certificate). As you can see in Fig. 2, the PSC-cert accompanies the service result returned to the service consumer. This PSC-cert allows a client to test that the code is PSC while the code itself is not revealed. There can be diverse variations of this general scenario. For example, after the step (2), the client asks the processor for the execution of the code and the processor manages the communication with the verifier and the compiler to get the PSC. We will use the following methodology to develop the model outlined here: (1) we will describe in detail concepts and relationships among actors in the model and (2) study in more detail the relationships with SOA and Web Services Architecture.

3 Service Implementation by WSbSC


In this section a specific use of WSbSC to offer an advanced level of end-to-end service security is described. We consider a consumer entity that uses a service offered by a provider entity. Fig. 2 shows how a provider entity relies on WSbSC to get a higher security level.
[I] Data input

Consumer Entity
Result+PSC-Cert [II]

Provider Entity
[10] [1]

Consumer Policy [9]

PSC
[0]

Processor
[8] [5]

Supplier
[4] [7] [6] [2] [3]

Author

Compiler

Verifier

Fig. 2. Service Implementation with WSbSC

554

E.R. Priego and F.J. Garca

Applying WSbSC, interactions in this basic scenario are: (I) a consumer entity requests a service from a provider entity. The security policy of consumer entity establishes that the provider entity must implement the service using WSbSC and, therefore the provider entity must get a PSC of the service implementation to achieve this policy. (0-9) The provider entity, if it hasn't done so previously, carries out the process of creation, supply, validation and generation of the PSC and executes the service. (II) It returns the result of the service together with the PSC-cert. Note that (0-9) illustrate another case in which the provider entity delegates in the supplier the process to get the PSC. By means of PSC-cert, the consumer entity can obtain an extra security level that certifies that the service was created, supplied, verified, compiled and executed by trust entities without being necessary to know the code itself. There can be diverse variations: e.g., the provider entity could submit a copy of the code, encrypted with the verifier's public key. If we suppose that both the consumer and the provider entities trust the verifier, then the consumer entity could request code validation to the verifier. Code confidentiality is guaranteed by encryption, and the verifier's public key encryption guarantees that only the verifier can decrypt, analyze and evaluate the code validity. Periodical tests and the use of several verifiers can improve security even more. To illustrate the work to be performed, the following listing outlines the structure of a PSC-cert in a simple case. <wsbsc:psc xmlns:wsbsc=.. xmlns:uddi=.. xmlns:ds..> <wsbsc:code EncodingType="Base64">cHVibG..</wsbsc:code> <wsbsc:psc-cert> <wsbsc:AuthoredCode> ..</wsbsc:AuthoredCode> <ds:Signature ..> ..</ds:Signature> <wsbsc:SuppliedCode> (a) </wsbsc:SuppliedCode> <ds:Signature ..> ..</ds:Signature> <wsbsc:CompiledCode>.(a).</wsbsc:CompiledCode> <ds:Signature ..> ..</ds:Signature> <wsbsc:VerifiedCode>.(a).</wsbsc:VerifiedCode> <ds:Signature ..> ..</ds:Signature> </wsbsc:psc-cert> </wsbsc:psc> AuthoredCode block is added at point 0 together with autor's signature of that block. The following blocks are added in the same way by each actor when they have finished their tasks. Note that sections marked with (a) consist of two main parts: metadata related to the actor (description, e.g., by means of uddi business entity, credentials, e.g., SAML authorization credentials, etc.) and metadata about its action, e.g., for the compiler: the compiler environment, the target language, and so on. This section has outlined one of the alternative interaction scenarios among consumers and suppliers. In order to finish developing this section, we will (1) study more alternative interaction scenarios, (2) select the most suitable web services standards to implement PSC, (3) develop the WSbSC security model extending the WS-SecurityPolicy model, and (4) we will develop an actual case relevant enough to illustrate the different alternative scenarios.

Securing Code in Services Oriented Architecture

555

4 Contribution, Related Work, Status and Future Work


Several solutions about mobile code has been proposed in the last years: e.g., [4,5,6] focus on execution environment (compiler, verifier and/or processor). [7] and more recently [10] suggest a contract between producer and consumer of mobile code. [11] defines a model-driven approach for service-oriented software development. The main contribution of this paper is the proposal of a new approach to the problem of the security of mobile code, WSbSC, that its based on SOA-RM and the Web Services Architecture. WSbSC provides a level of security that covers not only the data but also the code that process these data. A lot of work must be done, both to specify the demanded policy and the process that must be preformed to implement it (perhaps using WS-SecurityPolicy or even BPEL), and in order to select the standards to be used at each part of the PSC-cert (SAML, WS-Policy, WS-Addressing, UDDI, and so on). As a future line of research we are planning to extend the model to portable objects, i.e., securing the object state as well as the code that manages that state (behavior), making this code PSC. Acknowledgments. Partially supported by Comunidad Autnoma de La Rioja, project ANGI-2005/19.

References
1. Web Services Architecture (February 2004) http://www.w3.org/TR/ws-arch/ 2. Reference Model for Service Oriented Architecture v1.0 October 2006 http://docs.oasisopen.org/soa-rm/v1.0/soa-rm.pdf 3. Seshadri, A., Luk, M., Perrig, A., van Doorn, L., Khosla, P.: Externally verifiable code execution. Communications of the ACM (September 2006) 4. Franz, M., Chandra, D., Gal, A., Haldar, V., Reig, F., Wang, N.: A portable Virtual Machine target for Proof-Carrying Code. In: Proceedings of the 2003 workshop on Interpreters, virtual machines and emulators (June 2003) 5. Yau, S.S., Prasad, A., Zhou, X.: An Object-Oriented Approach to Containing Mobile and Active Codes in Large-Scale Networks, words. In: Fourth International Workshop on Object-Oriented Real-Time Dependable Systems (WORDS99) (1999) 6. Claessens, J., Preneel, B., Vandewalle, J.: How can mobile agents do secure electronic transactions on untrusted hosts? A survey of the security issues and the current solutions, ACM Transactions on Internet Technology (TOIT) (February 2003) 7. Sekar, R., Ramakrishnan, C.R., Ramakrishnan, I.V., Smolka, S.A.: Model-Carrying Code (MCC): a new paradigm for mobile-code security. In: Proceedings of the 2001 workshop on New security paradigms (September 2001) 8. Whitman, M.E.: Enemy At The Gate: Threats To Information Security. Communications of the ACM (August 2003) 9. Sima, C.: Are your web applications vulnerable? (October 2004) http://www. securitydocs. com 10. Security of Software and Services for Mobile Systems (March 2006) http://www.s3ms.org 11. SENSORIA (October 2004) http://sensoria.fast.de/

Securing objects in Services Oriented Architecture


Emilio Rodriguez Priego and F.J. Garca
Departamento de Matemticas y Computacin Universidad de La Rioja Edificio Vives, Luis de Ulloa s/n E-26004 Logroo {emilio.rodriguez, francisco.garcia}@unirioja.es

Abstract. Service Oriented Architecture (SOA) and Web Services are claiming a lot of interest because, using robust technologies like Internet and XML, they can address old problems related to interaction between potentially remote systems. Nowadays, security solutions focus on messages and data, but they forget the code security. In certain situations (parallel computing, hosting of processes, etc.), it may be convenient the exchange of code, and, in a more general case, code plus state (objects). Moreover, although code and/or state not being exchanged, we propose that any security approach will be incomplete if both data and code security are not addressed. In this paper, we extend a previous approach about securing code in SOA. We analyze general problems related to the exchange of code and state in SOA and in the specific case of Web Services architectures. A new general model of security is presented. This model covers any aspect related to the authorship, distribution, transformation, execution and validation of both code and data. Keywords: Web services security, mobile code security, Service Oriented Architecture

1. Introduction
The current interest in Web Services technology and Service Oriented Architecture (SOA), whose Reference Model has been recently approved as an OASIS standard [14] is notorious. That model represents a conceptual framework for interactions between consumers and providers of services. Basic concepts treated by SOA-RM are: service, visibility, interaction, execution context, policies, contracts, and so on, being security one of the critical aspects. SOA can be applied both in

local (e.g.,. intranet) and public (e.g.,. Internet) environments and its in the last case where the security importance is more releveant. On the other hand, Web Services Architecture (WSA) [18], approved as W3C Working Group Note, provides a conceptual model and a context for understanding web services. SOA and WSA Architecture share common concept. WSA can be seen as a specific application of SOA model. Currently, most works related to SOA are developed under Web Services Architectures. In this context, a lot of web services standards are evolving, most of them about security issues. SOA-RM focuses on the service as a central concept of interaction between a generic consumer and a provider. It defines service as a mechanism to enable access to one or more capabilities and its implementation is typically hidden from the service consumer except for (1) the information models exposed through the service interface and (2) the information required by service consumers to determine whether a given service is appropriate for their needs. So, SOA-RM states that the consequence of invoking a service is a realization of one or more real world effects such as response to a request, a change to the shared state of defined entities or some combination of both. Policies and contracts are other SOA central concepts, particularly related to security policies. Most SOA based solutions are based in web services technologies and security mechanisms. They put their focus on end to end integrity, confidentiality, identity and authentication. These mechanisms work well and, above all, they are applied to messages. However, code security is not generally addressed, whilst it is well known

that most threats to the integrity of the information are precisely focused not on the data directly but on the code that manages it [12]. This paper is the continuation of a previously presented work [7]. In that work, we presented an approach about code security on SOA environments that can be applied on web services architectures. We named that approach Web Services based Secure Code (here-in-after WSbSC) and its reference model WSbSC-RM. This paper aims to extend WSbSC reference model in a more complex situation in which entities wish to exchange not only data, but also objects as input and/or output data. The remainder of the article is organized as follows. Section 2 is devoted to show some background necessary to understand the rest of the paper. Section 3 describes how can to be extended WSbSC from a object-oriented perspective. Section 4 deals with performance issues and paper finalizes with related work, contribution and future work.

2. Securing code in SOA


In order to make the rest of the paper self contained we are devoting this section to present some background already published in [7]. In that paper we presented three central concepts: WSbSC-RM, WSbSC, PSC and PSC-cert. 2.1. WSbSC-RM WSbSC-RM: is an abstract framework for understanding significant relationships among service entities (providers and consumers) that allows an integral (data and code) secure interaction. This model enables the development of specific architectures using consistent standards or specifications. WSbSC-RM relies on SOA-RM but it adds new concepts and relationships to the modeling of data and code exchange based on services, and more specifically on web services architecture. The central concept in WSbSC-RM is the code, just as it has been defined traditionally but with some specific features: it can be portable, executed in any compatible execution environment; transmission, load and execution of the code can be carried out in a safe way, and it can be verified in a secure manner.

WSbSC-RM states that the transmission, reception, execution, load, compilation and validity of the code are services that can be offered by systems potentially remote and weakly coupled. As we see below, with WSbSC code is not only externally verifiable [2], but also externally compilable and externally executable. WSbSC-RM distinguishes these actors: Author: it's the owner and creator of the code and its legal owner. Supplier: provides the code to a consumer and distributes it with the author permission. Client: uses the code provided by a supplier. Verifier: verifies the code according to a security policy previously established. Compiler: given a code, it compiles another functional equivalent code. Processor: possesses an execution environment that executes the code. All WSbSC-RM actors are service consumers or providers, from the point of view of SOA-RM. Besides WSbSC-RM allows the modeling (recursively) of the actions (local or remote) of a service by composing services offered by these actors and according to code-centric policies and contracts. What is a key added factor of our approach with reference to SOA is that actors playing the role of consumers in any relationship to a provider may impose a certain security policy to regulate the service that the provider is going to perform. And this policy, and here is the contribution, does not only affect the data and the message as SOA does, but also the service implementation. This policy refers to one or several security aspects (such as integrity, confidentiality, validity, and so on) and may specify a mechanism or set of mechanisms that the provider must implement in order to

Figure 1 General WSbSC-RM

<wsbsc:psc xmlns:wsbsc=.. xmlns:uddi=.. xmlns:ds..> <wsbsc:code EncodingType="Base64">cHVibG..</wsbsc:code> <wsbsc:psc-cert> <wsbsc:AuthoredCode> ..</wsbsc:AuthoredCode> <ds:Signature ..> ..</ds:Signature> <wsbsc:SuppliedCode> (*) </wsbsc:SuppliedCode> <ds:Signature ..> ..</ds:Signature> <wsbsc:CompiledCode>.(*).</wsbsc:CompiledCode> <ds:Signature ..> ..</ds:Signature> <wsbsc:VerifiedCode>.(*).</wsbsc:VerifiedCode> <ds:Signature ..> ..</ds:Signature> </wsbsc:psc-cert> </wsbsc:psc> Figure 2 Outline of a PSC-cert structure accomplish the policy. The response to each service request will include, as well as the result, metadata about the required, and fulfilled, policy. 2.2. WSbSC 2.3. PSC and PSC-cert WSbSC-RM can be applied in different scenarios where relations between actors and real world entities can vary. We can illustrate these relationships by describing a general example that shows some key concepts in SOA-RM: service, interaction, policies and contracts, real world effect, etc. Fig. 1 shows this general scenario. Interactions involve the following steps: (1) An author creates the code and sends it to a supplier for distribution. (2) A client localizes and requests the code that satisfies its needs from the supplier and the supplier delivers the code. (3) The client requests the verification of the code according to the client policy from a verifier and the verifier delivers the validated code. (4) If code is not compiled for the architecture in which is going to be executed then the client requests its generation from a compiler. The compiler returns the compiled code. (5) The client can request validity of the compiled code from the verifier. The verifier returns the validated code. (6) The client requests to a processor execution of the code and the processor returns the result of the process to the client. At point (5) the code is associated to the verifier's signature that guarantees its integrity. The Processor can verify code integrity, or even As we have seen above, each step generates metadata signed by the service provider, as well as its signature; e.g., the code that results from the compiler can include metadata related to that compilation. This means that at the end of the process we can get a code qualified as "secure" since it's created (author), provided (supplier), validated (verifier) and generated (compiler) by trusted identified entities. This code, that we'll name Portable Secure Code (PSC) is formally "portable" and "secure". We have that PSC = Code + PSC-cert (cert stands from certificate). There can be diverse variations: e.g., the provider entity could submit a copy of the code, encrypted with the verifier's public key. If we suppose that both the consumer and the provider entities trust the verifier, then the consumer entity could request code validation to the verifier. Code confidentiality is guaranteed by encryption, and the verifier's public key encryption guarantees that only the verifier can decrypt, analyze and evaluate the code validity. Periodical tests and the use of several verifiers can improve security even more. Fig. 2 outlines the structure of a PSC-cert in a simple case. First of all, AuthoredCode block is correctness with respect to a certain specification, before execution by means of that signature. Moreover, the overall process can be checked if each actor signs its action.

added together with authors signature of that block. The following blocks are added in the same way by each actor when they have finished their tasks. Note that sections marked with (*) consist of two main parts: metadata related to the actor (description, e.g., by means of UDDI business entity; credentials, e.g., SAML authorization credentials, and so on.) and metadata about its action, e.g., for the compiler: the compiler environment, the target language, and so on.

3. Information exchange scenarios


In the next sections we describe a specific use of WSbSC-RM to offer an advanced level of endto-end service security using objects, like elements exchanged, assuming that an object is data plus code. We also show how to apply an analogous approach in order to secure the object state and the whole object (state + methods). Figure 3 shows the general picture of the three basic scenarios where a consumer entity requests a service from a provider entity. In the first case (3.a), the consumer and the provider entities exchange only data. This is the common information model found in SOA. In it, and for the particular case of Web Services, common security mechanisms such as public-key cryptography can be used to securing only the exchanged data (WSSecurity, XML-DSIG, SAML, WS-Policy, ).

The second case (3.b) corresponds to an scenario like the one described in section 2. So far, we have proposed a model in which the secured code is located in the service provider. The next step in the discussion is the study of a scenario where the code travels between consumers and service providers. Code may travel and not be locally executed for performance reasons, for example [6]. Case 3.c depicts this new scenario. In it, the service requires an object from the consumer as input. During its execution, the service will interact with this object and eventually it will modify the object state. The object, in turn, helps the service to fully accomplish its mission, allowing the service to use its methods. E.g., imagine that the scenario corresponds to the interaction between a flight reservation service and final users, who send their personal planner object. The service needs to consult the planner calendar to determine the user availability, and, once the flight has been selected, the service inserts a new appointment in the planner. Security requirements in case 3.c are more complex than for case 3.b, because the consumer and the provider want to ensure that not only the service (as in case 3.b) but its interactions (use and/or modification) with the input object are secure. Therefore, they agree to use WSbSC to get a higher level of security about the performed

Figure 3 WSbSC-RM Information Model Cases

service. But this is not enough yet. The security policy of the consumer requires that the provider access and/or modifies the object state only by means of the object methods. Figure 4 shows how we can achieve these high level security requirements for this scenario using WSbSC approach. Interaction begins when Consumer Entity A requests a service from provider entity B. Both A and B establishes security policies about code using WSbSC-RM. Lets suppose that the service requires a single object O1 as input, being M1 and M2 the object methods and S its state. The initial problem is that B does not allow untrusted code to execute. We can address this problem using WSbSC. First of all A has to get a certificate of both methods. If it hasnt done so previously, it follows steps described in section 2 and gets PSC-cert(M1) and PSC-cert(M2). This proves to B that code received from A is secure. 3.1. Securing objects state. WSbSS-RM A and B could need the same level of security for state than for code. Apparently, this is similar to case (3.a) where data can be secured by A and B using well-known security mechanisms. However, similarly to code, we can get a higher

level of security for the state. In the same way as was done for the code in section 2, we can distinguish actors related to objects state (data). We can consider that these actors virtually offer services about state: Owner: the owner of the state, A in Fig. 4. Note that state can represent relevant data that an entity owns. Supplier: optionally, the owner can be delegate in this actor the action of providing the state to another entity. Converter: optionally, it may be necessary to convert the internal state from one format into another without changing the state itself (it is similar to code compilation). Verifier: optionally, it verifies the data for consistency; e.g., the state can have a structure and the verifier tests this structure and the integrity of the state. Code Author Supplier Compiler Verifier Data Owner Supplier Converter Verifier

Table 1. Code/data actors duality

Table 1 shows code/data actors duality. In

Figure 4 Portable and secure objects with WSbSC

general, these actors can be local o remote; Using the analogy of WSbSC-RM for code, we can call the dual reference model for the state WSbSS-RM (Web Services based Secure State Reference Model). WSbSS-RM allows providing a further level of security on data with respect to scenarios such as the depicted in Fig 3.a. Consequently, the service consumer gets basic metadata related to the object state. Continuing the analogy with code, we will call this metadata PSS-cert (Portable and Secure State). This certificate will be generated by the data actors. 3.2. Securing objects state and methods At this point, the service consumer has metadata about the whole object (state and methods) that can be offered to another entity to demonstrate that all the methods have been created (author), provided (supplier), generated (compiler) and validated (verifier) by trusted actors that sign their actions with a certificate. Moreover, the state of the object has been identified (owner) and, eventually, it has been converted (converter) and validated (verifier) by trusted actors also. We call the certificate that aggregates both state and methods metadata PSOcert. In our example, PSO-cert(O1) = PSCcert(M1) + PSC-cert (M2) + PSS-cert (S). Therefore, going back to Fig. 4 schema, A sends B O1 with PSO-cert(O1). We assume that A and B trust actors described above; A and B may even share some of those actors. Now, B has received the code of M1 and M2. A should not allow the execution of O1 methods, and consequently its state access/modification, in an untrusted execution environment. Perhaps the M1 and M2 code is not suitable for its execution in Bs processor, so B has to transform it (e.g., compile to generate code compatible with its execution environment). When B returns the service result to A, it will have to certify that M1 and M2. or more precisely the recompiled versions of M1 and M2, were securely executed in B as WSbSC mandates, i.e., M1 and M2 has been compiled, verified and executed by trusted actors. This fact is returned to A in the form of M1 and M2 PSC-certs. Note that it isnt necessary to generate metadata from all WSbSC-RM actors. For example, if examining original M1 and M2 PSC-certs, B realizes that its compiler

environment is compatible with M1 and M2, B does not need to compile them again and it can use compiled code offered by A. B performs the service using M1 and M2 to access and/or modify O1 state. We want to borrow some ideas from SOA and stress the fact that they are also observed in WSbSC and WSbSS. Surely, when the service has finished, internal B state has been modified but as SOA-RM says internal actions that service providers and consumers perform as a result of participation in service interactions are, by definition, private and fundamentally unknowable. In fact, we can consider that A doesnt know either Bs internal actions to realize the service neither its initial nor final state; and B only handles O1 through its methods, without needing to know the method details. Although A and B dont know neither the process nor the state details, they have shared facts and processes from a real world point of view. Global process is distributed. SOA-RM focuses on the sets of facts shared by the parties. WSbSC-RM adds the focus on shared process too. A receives the results of the service including O1. Now O1 may have a new state S due to the interaction with B. A also receives: The PSO-cert (O1), that certifies that object methods are securely executed, verified, and eventually recompiled in a trusted environment; and that the objects state may have been converted and verified by trusted parties also. And the PSC-cert for the implementation of the service, that certifies that the service code also is secure as WSbSC mandates So, A can check integrity of M1, M2 (executed in B), S and the service implementation as was described previously. Note that for performance reasons, both consumer and provider havent to get PSO-certs every time. There is a trade-off between security and performance. Consumer and Provider policies have to state in which circumstances a PSO-cert update is required. 3.3. Securing legal access to state through object methods - WSbSO-RM It must be observed that, for the moment, the security level that the PSO-cert(O1) that B has

built offers is not enough. The service consumer A has not the sufficient guaranty to be sure that the new state S has been obtained my means of M1 and M2. In general, it must be guaranteed that the object state can only be managed by means of its methods, wherever the object is used. To reach such a guaranty, a new verifier actor is needed. While central problems about data and code verification have been addressed from different points of view, the problem of securing legal access to the state through the object methods is a more complex task, being the mobile agents scope the research field where the problem has been mainly addressed [10]. The verifier also adds metadata to the PSOcert(O1) and sign its information block in such a way that the consumer can also verify its identity and the verification itself. Following the notation used with WSbSC and WSbSS, we name Web Services based Portable and Secure Object Reference Model WSbPSO-RM. PSO-cert includes complete information about security of code, state and its relationship. WSbS*-RM can be applied independently, allowing diverse levels of security. Due to space limitations a more detailed discussion about that approach is avoided. However, as a future line of research, we are planning to address this problem from a WSbSORM perspective using secret sharing techniques. Another approach may be that the verifier reproduces the state modification following the same sequence of operations that B has performed. Therefore, Bs processor must provide the verifier with this sequence of actions, like it was a log file.

Security standard. In order to define PS*-certs, XML-Dsig, XML-Encryption, SAML and XMLSchema enable security and mechanisms to ensure all security issues described. Finally UDDI, is the most suitable standard to get a reference for the identity of each WSbS* actors. The described models define a general and perhaps the most complex scenario where all actors are different entities. In this case, PS* and PS*-cert could be introduce a significant overhead and a poor performance. We must consider some issues about performance: Roles of different actors can be played by a same entity, e.g., code verifiers, state verifiers and object verifiers of both service consumer and provider can be the same trusted Certificate Authority. This simplifies construction of PSC-certs and improves the performance. It isnt necessary PS*-certs to be obtained in every interaction. Providers and consumers policies can establish when they must be obtained, e.g., only at the beginning of the first interaction, by means of session mechanism, and so on. We state that WSbS* actors are always present in some way and in any scenario, but they do not necessarily adopt the form of web services. E.g., verifier actor role can be played by only one hardware component [17] and in this case, e.g., a CRC or another mechanism can be used in the PSC-certs.

5. Related work, Future Work

Contribution

and

4. Implementing the model with web services. Performance issues


In previous sections, a conceptual framework has been described based on concepts from SOA and WSA. We can outline how we can address the implementation of this model for each specific scenario using Web services standards. The central point in this approach is that both service consumer and provider have to define their respective security policies related to WSbS*-RM. Expression of these policies can be based on WSPolicy. On the other hand, PSO, PSC and PSS can be transmitted in a secure manner using WS-

A considerable amount of work, some of it rather old, has been done on several aspects treated here. [3,10,1] studied security aspects about Mobile code and Mobile agents and diverse solutions for specific security threats were proposed. Also, each one of the execution environment actors (compilers and processors, e.g., virtual machines [13] and verifiers [4,11]) have been presented from different points of view. Security contracts and policies were analyzed in [5,16] and more recently in [8]. The main contribution of our paper is the definition of a conceptual framework where all these approaches can be modeled. Besides, we propose an extra level of security in a service

interaction considering both code and state. Finally, an incremental model of security based on certificates issued by each model actor provides a means for ensure security and achieve a trusted environment. Our main lines of research are: (1) to work on the implementation of the model in several real world scenarios; (2) to improve security between state and methods using secret sharing tecniques (as commented in section 3.3).

Referencias
[1] Alfonso Fuggetta, Gian Pietro Picco, Giovanni Vigna, "Understanding Code Mobility," IEEE Transactions on Software Engineering, vol. 24, no. 5, pp. 342-361, May, 1998 [2] Arvind Seshadri, Mark Luk, Adrian Perrig, Leendert van Doorn, Pradeep Khosla, Externally verifiable code execution, Communications of the ACM, september 2006. [3] Aviel D. Rubin, Daniel E. Geer, Jr., "Mobile Code Security," IEEE Internet Computing, vol. 02, no. 6, pp. 30-34, Nov/Dec, 1998 [4] Bor-Yuh Evan Chang, Adam Chlipala, George C. Necula, Robert R. Schneck , The open verifier framework for foundational verifiers, Proceedings of the 2005 ACM SIGPLAN international workshop on Types in languages design and implementation, January 2005 [5] C. Gutirrez, E. Fernndez Medina and M. Piattini, Web Services Enterprise Security Architecture: A Case Study, SWS'05, november 11, 2005 [6] Danny B. Lange , Mitsuru Oshima, Seven good reasons for mobile agents, Communications of the ACM, v.42 n.3, p.8889, March 1999 [7] Emilio Rodrguez Priego, F.J. Garca, Securing Code in Services Oriented Architecture, ICWE07 (to be published). [8] European Project, Security of Software and Services for Mobile Systems, http://www.s3ms.org, March 2006 [9] European Project, SENSORIA, http://sensoria.fast.de, October 2004 [10] Joris Claessens, Bart Preneel, Joos Vandewalle, (How) can mobile agents do secure electronic transactions on untrusted hosts? A survey of the security issues and the

current solutions, , February 2003, ACM Transactions on Internet Technology (TOIT) [11] Karthikeyan Bhargavan, Cdric Fournet, Andrew D. Gordon, Verifying policy-based security for web services, Proceedings of the 11th ACM conference on Computer and communications security, October 2004 [12] Michael E. Whitman, Enemy At The Gate: Threats To Information Security, Communications of the ACM, August 2003 [13] Michael Franz, Deepak Chandra, Andreas Gal, Vivek Haldar, Fermn Reig, Ning Wang, A portable Virtual Machine target for ProofCarrying Code, Proceedings of the 2003 workshop on Interpreters, virtual machines and emulators, June 2003 [14] OASIS, Reference Model for Service Oriented Architecture v1.0
http://docs.oasis-open.org/soa-rm/v1.0/soa-rm.pdf

[15] Premkumar T. Devanbu, Philip W-L Fong, Stuart G. Stubblebine, Techniques for trusted software engineering, Proceedings of the 20th international conference on Software engineering, April 1998 [16] R. Sekar, C. R. Ramakrishnan, I. V. Ramakrishnan, S. A. Smolka , ModelCarrying Code (MCC): a new paradigm for mobile-code security, Proceedings of the 2001 workshop on New security paradigms, September 2001 [17] Trusted Computing Group (TCG). Implementing Trusted Computing, TPM Overview, TCG Specification Architecture Overview v1.2 [18] W3C, Web Services Architecture
http://www.w3.org/TR/ws-arch/

Apndice D

Presentaciones
En este Apndice se incluye una copia de la presentacin cuya exposicin se realizar en el Congreso ICWE07 que tendr lugar del 16 al 20 de Julio de 2007 en Como (Italia).

Securing code in Service Oriented Architecture


Emilio Rodrguez Priego F.J. Garca Izquierdo

International Conference on Web Engineering July 16-20, 2007 Como, Italy

Index

1.- Introduction 2.- Problem description 3.- Our solution

3.1 Starting point: SOA and WSA 3.2 WSbSC reference model 3.3 Service implementation with WSbSC

4.- Related work 5.- Conclusions, status and future work

Introduction

1-Introduction 2.- Description of the problem 3.- Our Solution 3.1 Starting point: SOA and WSA 3.2 WSbSC-RM 3.3 Service Implementation 4.-Related work 5.-Conclusions, status, future work

Growing interest in SOA and Web Services Security is a key factor adopting SOA and Web Services Current approaches to security focus on the message and data security A lot of standards are being developed, mainly by W3C and OASIS Application of standards is not enough

Problem Description

1-Introduction 2.2.- Problem Description 3.- Our Solution 3.1 Starting point: SOA and WSA 3.2 WSbSC-RM 3.3 Service Implementation 4.-Related work 5.-Conclusions, status, future work

Security efforts are mainly focused on trust entities, channel, message and data. Security problems about code are not usually addressed, i.e , code problems, bugs, viruses For a long time, a lot of research has been done about code mobility and security of the code Why are not we able to achieve acceptable code security level in SOA environments?

Our solution

1-Introduction 2.- Problem Description 3.3.- Our Solution 3.1 Starting point: SOA and WSA 3.2 WSbSC-RM 3.3 Service Implementation 4.-Related work 5.-Conclusions, status, future work

We need a model for security of code in service oriented architecture but

first, we need to improve SOA/WSA to consider code

Our starting point

SOA-RM Model WSA Model

SOA-RM: concepts & relationships


SOA-RM main concepts
Service Visibility Interaction Real world effect Service description Execution context Contract & Policy

1-Introduction 2.- Problem Description 3.- Our Solution 3.1 Starting point: SOA and WSA 3.2 WSbSC-RM 3.3 Service Implementation 4.-Related work 5.-Conclusions, status, future work

SOA-RM with shared process and Policy


Some new concepts and relationships:
Shared Process Contract & Policy are also related to Shared process

1-Introduction 2.- Problem Description 3.- Our Solution 3.1 Starting point: SOA and WSA 3.2 WSbSC-RM 3.3 Service Implementation 4.-Related work 5.-Conclusions, status, future work

Web Services Architecture


WSA
Its conformant to SOA Use XMLbased standards The channel is generally Internet

1-Introduction 2.- Problem Description 3.- Our Solution 3.1 Starting point: SOA and WSA 3.2 WSbSC-RM 3.3 Service Implementation 4.-Related work 5.-Conclusions, status, future work

Our solution: WSbSC reference model

1-Introduction 2.- Problem Description 3.- Our Solution 3.1 Starting point: SOA and WSA 3.2 WSbSCWSbSC-RM 3.3 Service Implementation 4.-Related work 5.-Conclusions, status, future work

Web Services based Secure Code is an abstract framework for understanding relevant relationships among actors participating in the code processing Code is a central concept with these features:

It can be portable and executable in compatible execution environments Code transmission, load and execution can be carried out securely It can be verified. Verification is known by the parties

Applicable to general scenarios and in particular:

Distributed processes Hosting or renting of processes

Our solution: WSbSC general scenario

1-Introduction 2.- Problem Description 3.- Our Solution 3.1 Starting point: SOA and WSA 3.2 WSbSCWSbSC-RM 3.3 Service Implementation 4.-Related work 5.-Conclusions, status, future work

Six main actors are involved in the execution of code and each one is important to security Each actor can virtually offer its service using a web services approach Actors can be systems, too Several scenarios are possible

WSbSC: PSC and PSC-cert

1-Introduction 2.- Problem Description 3.- Our Solution 3.1 Starting point: SOA and WSA 3.2 WSbSCWSbSC-RM 3.3 Service Implementation 4.-Related work 5.-Conclusions, status, future work

PSC is an XML representation of code. Its made up of the code itself plus a certificate (PSC-cert):

PSC=Code + PSC-cert

PSC-cert shows that code was created, provided, validated and generated by trusted identified entities, according to a previously negotiated policy. PSC-cert contains:

Identity of actors Credentials of actors Metadata of code Policy reference Signatures

Service Implementation with WSbSC

1-Introduction 2.- Problem Description 3.- Our Solution 3.1 Starting point: SOA and WSA 3.2 WSbSC-RM 3.3 Service Implementation 4.-Related work 5.-Conclusions, status, future work

How can we improve service security with WSbSC?

Service consumer establishes Policy including WSbSC Service provider must implement PSC-certs of that Service Service consumer can reject providers that dont apply code security

Service Implementation with WSbSC General Scenario

1-Introduction 2.- Problem Description 3.- Our Solution 3.1 Starting point: SOA and WSA 3.2 WSbSC-RM 3.3 Service Implementation 4.-Related work 5.-Conclusions, status, future work

A consumer requests a provider a service that accepts WSbSC The provider returns the result and the service implementation PSC-cert The service can be implemented using remote actors or local systems. In every case the provider must return the service implementation PSC-cert

Related Work

1-Introduction 2.- Problem Description 3.- Our Solution 3.1 Starting point: SOA and WSA 3.2 WSbSC-RM 3.3 Service Implementation 4.4.-Related work 5.-Conclusions, status, future work

Related research areas:

Mobile code security:

Proof-Carrying Code, Pioneer, Trusted Platform Module, ..

Mobile agents security:

Aglets, JADE, ...

Mobile devices security:

S3MS

Quality of web services:

WSOL, Oasis WS-Quality Model, WS-Agreement, MAIS

Software engineering for SOA:

SENSORIA

Conclusions

1-Introduction 2.- Problem Description 3.- Our Solution 3.1 Starting point: SOA and WSA 3.2 WSbSC-RM 3.3 Service Implementation 4.-Related work 5.-Conclusions, status, future work

Main contribution: proposal of new approach to the problem of mobile security with Web Services WSbSC it is based on SOA-RM and WSA WS security is focused on code It can be applied to both mobile code and implementation of web services

Status and Future work

1-Introduction 2.- Problem Description 3.- Our Solution 3.1 Starting point: SOA and WSA 3.2 WSbSC-RM 3.3 Service Implementation 4.-Related work 5.-Conclusions, status, future work

Status

We are working on defining XML PSC-cert structure, WSbSC policy and model implementation using WS standards

Future work

To extend the model to objects (PSO) considered as code (PSC) plus state (PSS). To use PSC-certs as the basis for the security policy in a real case

Thank you
emilio.rodriguez@unirioja.es

S-ar putea să vă placă și