Universidad de La Rioja

Departamento de Matemáticas y Computación

Memoria para optar a la concesión de la suficiencia investigadora y el Diploma de Estudios Avanzados

Código 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. Descripción del tema de investigación . . . . . . . . . . . . . . . 1.1. Introducción . . . . . . . . . . . . . . . . . . . . . . . . . 1.2. Motivaciones . . . . . . . . . . . . . . . . . . . . . . . . . 1.3. Objetivos concretos . . . . . . . . . . . . . . . . . . . . . Contribución . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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 código seguro basado en SOA . . 2.3.1. Comparación con SOA-RM . . . . . . . . . . . . 2.3.2. Ámbito de aplicación . . . . . . . . . . . . . . . 2.4. WSbSC-RM: Modelo de referencia de la Arquitectura de Código seguro basado en Servicios Web . . . . . . . . . . 2.4.1. Comparación con WSA . . . . . . . . . . . . . . 2.4.2. Descripción general de WSbSC-RM . . . . . . . 2.4.3. PSC y PSC-Cert . . . . . . . . . . . . . . . . . . 2.4.4. Aplicación de WSbSC a la Implementación de Servicios Web . . . . . . . . . . . . . . . . . . . 2.5. Modelos de intercambio de información con WSbSC . . . 2.6. WSbSS: Estado seguro basado en Servicios Web . . . . . 2.6.1. PSS y PSS-cert . . . . . . . . . . . . . . . . . . . 2.6.2. Dualidad Código-Estado . . . . . . . . . . . . . 2.7. Objetos seguros basados en Servicios Web . . . . . . . . . 2.7.1. Aproximación 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. Características 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. Implementación del modelo . . . . . . . . . . . . . . . . . 2.11.1. Implementación de las política de seguridad . . . 2.11.2. Implementación 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.

1

3.

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

39 42 46 49 64 65

Bibliografía . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A. Glosario B. Ejemplo de codificación en XML de PS*-certs C. Publicaciones y Trabajos presentados en Congresos D. Presentaciones

estrictamente hablando no parecen plantear nuevos paradigmas sobre los que iniciar una nueva etapa dentro del ámbito de las tecnologías de la computación. Esta aparente simplicidad y su semejanza o analogía con viejos conceptos ha creado no pocas confusiones sobre sus verdaderas implicaciones y sobre su verdadero significado y utilización. Ambos términos se refieren a áreas de conocimiento que están recibiendo un enorme impulso por la comunidad de especialistas en tecnologías de la información y. Por otro lado. La respuesta no puede ser otra que afirmativa. en la actualidad.1. ¿el entusiasmo que. Debe ser resaltado que los dos términos parten de definiciones sencillas e intuitivas que recuerdan a viejos conceptos y por tanto. SOA ha aportado la visión conceptual que permite comprender el modelo de intercomunicación mediante Servicios web. aún no se ha desarrollado un modelo estándar de seguridad que integre todos ellos y permita su utilización de una 3 . 10]. 1. han aparecido centenares de estándares promovidos por organismos internacionales como el W3C u OASIS. se sobreutilizan y se etiquetan exageradamente todo tipo de soluciones mediante SOA y servicios web. Entonces. y una gran parte de estos estándares ponen su punto de atención en la seguridad. como ya ocurrió anteriormente con otros paradigmas. el estudio de la seguridad al ser un concepto muy amplio y complejo suele referirse a un ámbito determinado. al contrario de lo que ocurrió con otros hitos en la historia de la computación como la programación estructurada o la orientación a objetos. de los servicios web.SOA y los Servicios web tienen el gran mérito de haber abierto el camino para solucionar un problema muy sencillo en su planteamiento y en absoluto trivial en su solución: la interoperabilidad entre sistemas potencialmente remotos y heterogéneos. concretamente. está permitiendo alcanzar la ansiada interoperabilidad entre sistemas heterogéneos sin las ataduras de las soluciones comerciales. es la seguridad uno de los aspectos que más interés despierta sobre todo porque para llevar a cabo con éxito proyectos prácticos este aspecto es crítico. durante varios años ya. generan estos conceptos está justificado?. y más concretamente. muchas de ellas replanteando viejos problemas en el nuevo marco que ofrecen estas dos nuevas áreas de conocimiento. En este contexto han surgido infinidad de líneas de investigación. muy especialmente. De hecho. La utilización de estándares en sí misma no garantiza alcanzar el objetivo de la interoperabilidad en un entorno seguro [42.1. Descripción del tema de investigación Introducción Los términos Servicios web y Service Oriented Architecture (SOA) vienen siendo utilizados con mucha frecuencia en los últimos años. por parte de los proveedores de soluciones tecnológicas. También. Alrededor de SOA y. Este hecho viene corroborado porque si bien existen diversos estándares relativos a seguridad en entornos SOA y servicios web. al fin. sino que además los estándares deben ser utilizados adecuadamente y de una manera integrada y todo ello no es en absoluto una tarea fácil.

al igual que ha ocurrido cuando se han aplicado a otros problemas como el intercambio seguro de datos entre aplicaciones. Los objetivos de este trabajo de investigación son resumidos a continuación: 4 . el código y su analogía con los datos (dualidad dato-programa). tecnologías) siempre han despertado mi curiosidad y los estudié con interés durante mis estudios de ingeniería de telecomunicaciones. Otra razón ha sido el convencimiento de que SOA y Servicios web pueden facilitar la interoperabilidad del código de una manera segura. la mencionada ausencia de un modelo unificado de seguridad ampliamente aceptado también es un estímulo para investigar un modelo que pueda ser aplicable al código y por extensión a objetos. en el ámbito laboral he tenido la oportunidad de trabajar en proyectos donde estos aspectos. la orientación a objetos y la seguridad (modelos. conceptos. son hoy en día de los menos estudiados comparados con otros ámbitos. como implementación de servicios. en sus distintas vertientes (como dato. 1. etc. principios. La aplicación adecuada de estándares basados en XML efectivamente abre perspectivas muy interesantes cuando se analiza la seguridad del código. Por último. etc. especialmente el de la seguridad. contribuyendo por tanto a cubrir uno de los aspectos menos estudiados. probablemente debido a que aún existen bastantes ámbitos donde no se han desarrollado estándares de seguridad aplicables.).manera conjunta y completa. Ésta ha sido una de las principales motivaciones para realizar esta investigación. movilidad del código. La identificación de casos reales en los que un modelo de seguridad con un enfoque SOA y de Servicios web puede ser aplicado representa un estímulo más para esta investigación. han sido importantes.3. área de informática. relaciones y flujos que intervienen en una interacción segura de código y datos. En especial. las Administraciones Públicas para intercambiar y reutilizar código aún en los casos más sencillos.2.). a pesar de que la seguridad del código sí ha sido estudiada en los últimos años desde otros puntos de vista (agentes móviles. por ejemplo. Objetivos concretos Definición de un modelo de referencia que sirva como base para comprender cuáles son las relaciones entre los diferentes actores. mi ocupación actual como Auditor de Tecnologías de la Información en un Organismo adscrito al Gobierno de La Rioja me ha permitido conocer desde un punto de vista bastante amplio la problemática de la falta de interoperabilidad del software. Por otro lado. Motivaciones Los aspectos de seguridad de SOA y Servicios web relacionados con el código. los serios problemas de seguridad que se presentan en la práctica y las grandes dificultades que tienen. Desde un punto de vista personal. 1.

Particularizar el modelo dentro de la perspectiva de SOA y Servicios web proponiendo un modelo de seguridad para la verificación de código en distintos escenarios. incluidos los que vienen determinados por el entorno tecnológico”. XML-signature. implementaciones y otros detalles concretos. WSDL. Extender el modelo del intercambio seguro de código mediante servicios web a la combinación de código más estado (objetos). 25]) relacionados con la investigación y que son necesarios para comprender mejor el punto de partida para el planteamiento del problema.1. axiomas y relaciones dentro de un determinado dominio y que es independiente de estándares específicos. Se pueden distinguir dos tipos básicos de arquitectura: Arquitectura de referencia “estructura que ofrece una solución abstracta a un problema en un determinado dominio”.) que tienen la suficiente madurez como para que en la práctica estén siendo 5 .1. Este conjunto forma un conjunto abstracto que permite comprender las principales relaciones entre las entidades de un entorno y el desarrollo de arquitecturas específicas que usen estándares o especificaciones aplicados a ese entorno” . WS-Security. muchos de ellos relacionados con la seguridad en Servicios web. etc. 2. 2. patrones y requisitos adicionales. 2. Las principales conclusiones del estudio fueron: Aunque algunos estándares no habían sido aún aprobados oficialmente y había un grupo de ellos que aún están en fase de aprobación. Se analizaron más de 30 estándares.2. SAML. existe un grupo básico (SOAP. Contribución Planteamiento del problema En esta sección vamos a describir algunos conceptos básicos (que pueden encontrarse en diversas fuentes tales como [2. Modelos de referencia y arquitecturas Creemos que es importante distinguir entre dos conceptos que habitualmente se confunden o utilizan indistintamente y que serán utilizados en nuestra investigación: Modelo de referencia “conjunto mínimo de conceptos. Estudio previo y punto de partida El punto de partida para la realización de la investigación fue un estudio previo de los estándares relacionados con Servicios web y el modelo de referencia SOA (en adelante SOA-RM). 2.1. Arquitectura concreta “implementación específica de una solución basada en arquitecturas de referencia. además en el Glosario (Apéndice A) se resumen todos los conceptos utilizados. tecnologías.

Agentes móviles El concepto de agente también ha sido estudiado en el pasado desde el punto de vista de los sistemas distribuidos y. sobre todo. Así. sobre la seguridad. Tanto los estándares 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 ningún caso abordan el problema de la seguridad del código. Su funcionamiento es autónomo. basándose en dicha Nota aprobó como estándar un modelo de referencia más genérico [25] pero que igualmente no aborda la cuestión de definir el modelo de seguridad básico en un entorno SOA. No hubo un gran consenso respecto a una arquitectura de servicios web. Se toma por tanto como punto de partida el SOA-RM y WSA. no existen unas especificaciones ampliamente reconocidas sobre Seguridad en servicios web”. es en la práctica uno de los aspectos básicos de la seguridad. para ahondar más sobre la seguridad del código se realiza un estudio de las cuantiosas referencias relativas a este aspecto dentro de dos áreas bien definidas: el código móvil y los agentes móviles: Código móvil La movilidad del código ha sido investigada durante mucho tiempo. tal como han constatado diversos estudios. la necesidad de ahondar más profundamente sobre la seguridad del código en el ámbito de los servicios web y SOA. En [4] se define como “la capacidad para reconfigurar dinámicamente y en tiempo de ejecución el vínculo entre los componentes software de una aplicación y su localización física dentro de una red”. se reconoce en la introducción que “En este momento. Tomando como referencia este último.utilizados con éxito y por tanto puedan ser tenidos en cuenta al abordar la investigación. el cual como se indicará más adelante. por ejemplo. El W3C trabajó en dicha cuestión teniéndose como resultado no un estándar sino una Nota del grupo de trabajo [2] titulada “Web Services Architecture” (en adelante WSA) que. el código es una de las fuentes principales de amenazas a la seguridad [15. 44]. De esta forma se identifica. principalmente en el ámbito de los sistemas distribuidos. los agentes son piezas genéricas de software con las siguientes características [5. aunque es tratada con cierta extensión en un apartado. OASIS. en especial el primero ya que ha sido aprobado finalmente como estándar recientemente y cuenta con una mayor aceptación. 6 . Posteriormente. Por otro lado. es decir. aunque contiene aspectos muy interesantes. reconoce que hay cuestiones aún no consensuadas y preguntas abiertas. De hecho. sin necesidad de intervención humana. desde el enfoque de la inteligencia artificial. realizan el proceso independientemente. 35]: 1. ya en este estudio previo.

con otros sistemas o con personas. generalmente enviados por usuarios finales a los cuales devuelven al final sus resultados. El concepto central del modelo es el Servicio que viene definido como: Servicio Mecanismo que permite el acceso a un conjunto de una o más capacidades. Interacción y Contratos/Políticas. Los ataques pueden ser de diversa naturaleza [20] y algunos autores argumentan que la protección total del código puede ser incluso imposible si no se establecen unas restricciones previas. Efectos en el mundo real.1. Pueden comunicarse entre sí. Generalmente las soluciones propuestas a los distintos problemas de seguridad pueden clasificarse como soluciones preventivas o de validación posterior. Los agentes móviles que pueden considerarse como un caso particular de código móvil. El modelo de referencia SOA se basa en siete conceptos básicos: Servicio. No existe una amplia bibliografía abordando el problema desde el punto de vista de la arquitectura de servicios web o SOA. repasaremos los principales conceptos incluidos en SOA-RM que están relacionados con la investigación. equivocadas o indebidas. Entorno de ejecución malicioso Aquí por el contrario se aborda el problema de seguridad desde el punto de vista del código que viaja a un entorno de ejecución que podría afectar a su funcionamiento. la gran mayoría de propuestas se centra en problemas muy concretos y generalmente en entornos locales. 2. 3. 46] y se ha centrado principalmente en la resolución de dos problemas básicos que surgen cuando un código viaja a través de una red para ser ejecutado en un entorno de ejecución remoto: Código malicioso Se trata del punto de vista del entorno de ejecución que debe abordar los problemas de seguridad que puede plantear la ejecución de un código externo cuyo comportamiento debe ser vigilado para que no realice operaciones potencialmente peligrosas. Pueden aprender en función de su entorno. 3. Modelo de referencia de código seguro basado en SOA Comparación con SOA-RM En este apartado.3. Su comportamiento puede mejorar a lo largo del tiempo cuando interactuan con su entorno y otros agentes o personas.2. 34. son agentes que pueden viajar de un equipo a otro. en el que el acceso se proporciona por una interfaz normalizada 7 . Descripción del Servicio. En cualquier caso.3. Contexto de ejecución. Visibilidad. con el fin de evitar confusiones sobre la terminología. 2. La seguridad del código referida a estos dos conceptos (código móvil y agentes móviles) también ha sido estudiada profusamente [5.

Sólo información y datos que son potencialmente intercambiados con un servicio son. el estado compartido.. Alguna combinación de 1 y 2 El estado compartido no necesariamente se refiere a las variables de estado determinadas que son almacenadas en un soporte físico. que no deberían tener conocimiento explícito de ellas. 8 . excepto para los modelos de información expuestos a través del interfaz del servicio y la información requerida por los consumidores del servicio para determinar si éste es apropiado a sus necesidades. La información devuelta en respuesta a una petición de dicha información 2. Y añade. la visión pública del servicio incluye efectivamente los efectos producidos por las acciones. privadas y fundamentalmente desconocidas. El Modelo de comportamiento caracteriza el conocimiento sobre las acciones. se establece que Un servicio es opaco en el sentido de que su implementación es típicamente oculta para el consumidor del servicio. respuestas y dependencias temporales entre las acciones de un servicio. En su definición de Interacción introduce otros conceptos como: El Modelo de información de un servicio es la caracterización de la información que puede ser intercambiada con el servicio. Por el contrario. nosotros nos centramos en el conjunto de hechos compartidos por las partes. Es decir. En primer lugar en la descripción de Servicio. y el efecto del mundo real de una interacción de servicio es la acumulación de los cambios en el estado compartido. Respecto a “Efectos del mundo real” (de “Real World Effects” en [25]). incluidos dentro del modelo de información del servicio. pudiendo ser éstos: 1. por definición. sin embargo. indica que: Como consecuencia de la invocación de un servicio se producen uno o más efectos del mundo real. Un cambio en el estado compartido de las entidades definidas 3. SOA-RM no prohíbe que la implementación no sea oculta pero indica que lo habitual es que el consumidor no conozca tal implementación.). entendiéndose por desconocidas que participantes externos no pueden ver las acciones privadas de otros y. en general. (. Las acciones internas que los proveedores y consumidores de servicios realizan como resultado de su participación en las interacciones del servicio son. Una gran parte del comportamiento que se produce como resultado de una acción puede ser privado.y cuyo uso es ejercido consistentemente mediante restricciones y políticas especificadas en la definición del servicio.. más aún. Para nuestro estudio nos centramos en cuestiones planteadas en la descripción de alguno de estos conceptos de SOA-RM que es necesario revisar para poder ampliar este modelo hacia un modelo que soporte código seguro. sino que representan la información compartida sobre las entidades afectadas. Las acciones de los proveedores y consumidores del servicio conducen a modificaciones de este estado compartido.

Figura 1: Relación entre conceptos en SOA-RM 9 .

El código como dato: en algunas situaciones (§ 2. así como otros subconceptos asociados. puede tratarse del código que implementa el servicio. 2. teniendo que ser en ese caso conocido por la otra entidad (consumidor o proveedor). Así por ejemplo imaginemos un consumidor que solicita un servicio de reserva de vuelos a un proveedor. En definitiva.2) la información intercambiada a la que alude el modelo es código. 2.Finalmente. también puede definirse como efecto de un servicio la compartición del proceso entre el proveedor y el consumidor. El “Efecto del mundo real” producido no sólo ha sido la compartición de un estado conocido por ambas partes (la reserva de vuelo) sino también la compartición de un proceso también conocido por ambas partes (el proceso de anotación en la agenda y el proceso de obtención del billete del vuelo). Incluso. Esto permite asociar este modelo con las áreas de código y agentes móviles indicadas previamente y sienta las bases para plantear un modelo de seguridad donde además de la seguridad del dato también se considera la seguridad del código como elemento fundamental para alcanzar el mayor grado de seguridad en una interacción de servicios. pueden también restringir aquellos Efectos del mundo real que se esperan cuando se usa un servicio. Como puede observarse en la figura 2. Una Política representa algún requisito o condición sobre el uso. como. Como resultado se efectúa la reserva y la anotación de una cita en la agenda para el día del vuelo.3. Dicho consumidor podría poseer una agenda en la que almacena sus citas. Ambos. Ámbito de aplicación Aunque nuestro modelo es virtualmente aplicable a cualquier escenario SOA en el que se considere el código como un aspecto importante de seguridad. se representan la totalidad de las relaciones propuestas entre los siete conceptos definidos en SOA-RM. nuestro enfoque consiste en aplicar la dualidad dato-código y estado-proceso al modelo de referencia SOA. SOA-RM introduce los conceptos de Política y Contrato. En la figura 1. despliegue o descripción de una entidad definido para cualquier participante.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 métodos que interacciona con la implementación del servicio de reserva de vuelo del proveedor. 10 . De manera similar a cómo el proveedor y el consumidor comparten un estado que refleja un efecto en el mundo real.2. Un posible escenario (cuyo modelo genérico se describe en § 2. 3. el proceso ha sido compartido tanto por el consumidor como el proveedor. Un contrato representa un acuerdo entre dos o más partes. Proceso compartido: es el concepto análogo al estado compartido que indica SOA-RM.3. Políticas y contratos sobre código: las políticas y los contratos que se aplican a Servicios también pueden reflejar restricciones sobre el código como dato intercambiado (portabilidad) y/o como implementación de las acciones de un servicio. Nuestra propuesta es introducir nuevos conceptos que amplíen SOA-RM para permitir abordar la seguridad del código en una arquitectura SOA: 1. como veremos más adelante.

definido como: Servicio web sistema software diseñado para soportar una interacción extremo a extremo interoperable sobre una red. Aquí el concepto central es Servicio web. su integridad y/o su portabilidad cobran una enorme importancia. el código en sí. es el alquiler de procesadores para realizar cálculos que requieren una alta capacidad de proceso Servicios de auditoría / certificación / validación de código por parte de una o diversas entidades reconocidas Servicios de homologación de código Bibliotecas de código accesibles y reutilizables tanto de código abierto como comercial Servicios de optimización de código 2.Figura 2: Comparación con SOA hay determinados ámbitos de aplicación en los que la visibilidad del código.4. se ofrecen o intercambian como parte de los servicios proporcionados por el proveedor de los mismos. cuyo modelo ya citado es anterior a SOA-RM y aunque no fue aprobado como estándar introduce y define conceptos que serán útiles para nuestro estudio.4.1. 2. la fuente del código o todos estos elementos. puesto que bien sólo la integridad del código. Los servicios web tienen un 11 . Un caso particular. Ejemplos típicos de estos ámbitos de aplicación son los siguientes: Servicios de proceso distribuido Servicios de albergue u hospedaje de procesos. WSbSC-RM: Modelo de referencia de la Arquitectura de Código seguro basado en Servicios Web Comparación con WSA SOA-RM tiene su principal aplicación en WSA.

Por otro lado. 2. Un actor puede asumir uno o más roles. a diferencia de SOA-RM. Otros sistemas pueden interacturar con un servicio web tal como ha sido definido en su descripción. hace una distinción entre Personas u Organizaciones y agentes: Persona u organización : se refiere a personas u organizaciones reales que pueden ofrecer o solicitar servicios web. WSA. En la Figura 3 se describe un esquema general de funcionamiento de la arquitectura de servicios web 12 . personas. organizaciones.Figura 3: Esquema general de servicios web interfaz descrito mediante un formato que puede ser procesado automáticamente (concretamente WSDL). [1] indica dos definiciones posibles del concepto de actor: 1. usando mensajes SOAP. No debe confundirse este concepto de Agente con el ya indicado proveniente del área de inteligencia artificial que se refiere a código móvil autónomo. Agente : es un programa que actúa en nombre de una persona u organización. pertenecer a un determinado dominio en el que pueden establecer políticas que gobiernen los recursos que poseen. software. Persona u organización que puede ser propietaria de agentes que solicitan el uso o proveen servicios web. etc. máquinas. Un actor en un nivel de abstracción puede ser visto como un rol en un nivel de abstracción inferior. típicamente transmitidos usando HTTP y serialización XML en conjunción con otros estándares relacionados con la Web”.) que puede realizar acciones. Entidad física o conceptual (por ej.

compilación. reglas de verificación de código compilado [31. Cliente: usa el código proporcionado por un suministrador. El modelo WSbSC-RM define los siguientes actores: Autor: creador del código y su propietario legal. corrección. etc. con algunas características específicas: Puede ser portable Puede ejecutarse sobre cualquier entorno de ejecución compatible Su transmisión.4. carga y ejecución puede ser realizada de forma remota pero aplicando unas condiciones mínimas de seguridad previamente acordadas Puede ser verificado para comprobar determinados aspectos como integridad. El principal objetivo de WSbSC-RM es definir un modelo a partir del cual sea posible construir arquitecturas concretas en las que la transmisión. 45]. En definitiva. sino también externamente compilable y externamente ejecutable. Proof Carrying Code [30]) . que el código no sea únicamente externamente verificable en un entorno local [36]. WELL [19]). carga. ejecución y validación del código sean servicios que puedan ser ofrecidos por sistemas potencialmente remotos y cuya política de seguridad sea acordada por los actores intervinientes en el proceso mediante la creación de lazos de confianza entre ellos. proporcionando pruebas de que se trata de un código seguro conforme a dicha política. la cesión del código a un tercero para su distribución. reglas de construcción de código seguro a nivel de código fuente (por ejemplo. recepción. inclusión de pruebas genéricas anexionadas al código (por ejemplo. veamos nuestra definición de un modelo de referencia de una arquitectura basada en servicios web orientada a código seguro y que denominaremos WSbSC-RM (Web Services based Secure Code Reference Model). etc. como por ejemplo. Las comprobaciones que puede realizar el validador son muy diversas y no están limitadas por el modelo sino que son definidas conforme a técnicas específicas de validación. etc. 13 . Validador: verifica el código conforme a una política de seguridad previamente acordada entre el cliente y el suministrador. En WSbSC-RM el concepto central es el código tal como ha sido definido tradicionalmente [43]. la integridad del código [37].2. su corrección respecto a reglas específicas tales como aserciones [45].2. Descripción general de WSbSC-RM Una vez vistos los conceptos básicos en SOA-RM y WSA. Entre los servicios que puede ofrecer el autor se encuentran la mejora del código proporcionando nuevas versiones del mismo. Suministrador: proporciona el código a un consumidor o cliente y los distribuye con el permiso del autor. pero. como vemos a continuación.

Alguno de los servicios que el procesador puede ofrecer son: ejecución de pruebas de validación asociadas al código [30]. (7) El generador devuelve el código compilado al cliente. (4) El cliente pide al validador la verificación del código conforme a la política que tenga establecida el cliente.Generador: a partir del código obtiene otro código mediante transformación (compilación) funcionalmente equivalente y que es compatible con el entorno de ejecución proporcionado por el procesador. nótense cómo el concepto de actor es usado de forma ligeramente diferente en SOA-RM. En general. Java Virtual Machine. (9) El validador devuelve el resultado de la validación del código compilado. (8) Eventualmente. (6) Si el código suministrado no ha sido compilado para la arquitectura en la que va a ser procesado. Procesador: posee un entorno de ejecución en el que ejecuta el código proporcionado y devuelve el resultado de dicha ejecución. una matriz de microprocesadores). 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. Por tanto. En la Figura 4 se muestra un escenario con las interacciones entre cada uno de los actores en un caso genérico. WSA: el concepto es similar (también son personas u organizaciones). (10) El cliente solicita al procesador la ejecución 14 . Las interacciones entre los actores implican los siguientes pasos (1) El autor crea el código y lo envía a un suministrador para su distribución. preparado para su verificación por el validador [31]). el cliente solicita al compilador su generación (y eventualmente. el cliente puede solicitar al validador que compruebe si el código generado es correcto conforme a la política establecida. 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 organización sino un sistema hardware o software. servicios especiales tales como máquinas virtuales que facilitan la validación del código [14].4). pero se añade el concepto de Agente como el software que realiza las acciones del servicio en nombre de un determinado actor. (3) El suministrador suministra el código solicitado al cliente como respuesta a su petición. Un entorno de ejecución podrá ser virtual (por ejemplo. JVM) o físico (por ejemplo. se encuentran: optimización de código para un entorno de ejecución determinado. (2) Un cliente localiza a un suministrador y le solicita el código que satisface sus necesidades. etc. WSbSC-RM: entendemos que la definición de actor que más se adecua al modelo es la segunda acepción (ver § 2. generación de código con características especiales (por ej. entre los servicios ofrecidos por un generador. su optimización para esa arquitectura). (5) El validador entrega el resultado de la validación. Uno de los aspectos diferenciales del modelo es que admite diferentes escenarios que van desde la interacción mediante servicios web entre los actores (potencialmente remotos) hasta la misma interacción realizada en un único sistema local en el que los actores son sistemas hardware o software. etc.

Figura 4: Escenario General de WSbSC-RM del código indicándole el entorno de ejecución donde quiere que sea ejecutado (en caso de que el procesador soporte más de un entorno de ejecución) y el lenguaje en el que el código ha sido compilado. Se entiende que este flujo de acciones es el genérico en el que todas tienen éxito. Esto conduce de forma directa a una filosofía de modelo extensible. el cliente no localiza el código adecuado conforme a su política y por tanto debe plantearse la elección de otros suministradores/autores. Sin embargo. La validaciones efectuadas por el validador son las más críticas. WS-Policy [41]. Como veremos más adelante. los actores y sus relaciones y deja abiertas las técnicas de validación o las características frente a las cuales se valida el código. 15 . mientras que los detalles de los metadatos asociados a cada uno de los actores es dependiente de la técnica empleada. que se ha aplicado con éxito a algunos estándares cuya pretensión es ser “contenedores” de soluciones en lugar de enumerar un conjunto limitado de posibilidades cuya ampliación conduciría indefectiblemente a la modificación del estándar para incluirlas. aplicado a mensajes da como resultado WS-SecurityPolicy [28] que es un contenedor de aserciones de políticas de seguridad en un intercambio de mensajes. eventualmente. El modelo se centra en el proceso. Así por ejemplo. si como resultado de la primera validación (paso 4) el validador informa que el código entregado por el suministrador no puede validarse afirmativamente. Otras excepciones que podrían producirse son: el compilador no acepta el formato del código para su transformación al entorno de ejecución del procesador. solicitar al autor una corrección en el código para satisfacer la prueba de validación exigida. el cual a su vez podría. (11) El procesador devuelve el resultado del procesamiento del código al cliente. Por ejemplo. el cliente puede optar por indicar este evento al suministrador. etc. podrán darse en cada caso las excepciones correspondientes en cuyo caso el código no sería ejecutado. el objetivo es definir una estructura del certificado asociado al proceso de ejecución del código.

Nuestra propuesta es que en el punto (9) el código esté asociado a la firma del validador. 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. antes de la ejecución mediante esa firma. Para ilustrar cómo puede conseguirse con nuestro modelo una certificación del proceso en relación con la identidad. debe estar especificado en la política de seguridad asociada al proceso. en este caso el valor inicial de la identidad será no tanto por el identificativo del actor (un dispositivo) sino por cuáles o con qué condiciones se define su comportamiento. si un código no es válido no tiene sentido efectuar su compilación y. no puede ser entregado al procesador para su ejecución. como hemos indicado. la aplicación de criptografía de clave pública para efectuar la firma de los metadatos generados por los actores. gracias a la identificación y determinación de los actores mencionada. Más aún. La aplicación de técnicas concretas para la implementación del modelo de referencia en arquitecturas de referencia o arquitecturas concretas. validó y procesó el código. el tratamiento de estas circunstancias como requisito o no. la cual garantiza su integridad. Podría decirse que sabremos “quién es” por cómo realiza sus acciones. volvamos al escenario descrito anteriormente. Así por ejemplo. conceptos y el flujo del proceso de producción y ejecución del código. Nótese que aunque alguna de las funciones descritas no sea realizada mediante servicios web. si el código compilado no recibe la aceptación por parte del verificador. puede implicar la aparición de otros actores específicos de esas técnicas. Pero en cualquier caso. El procesador puede verificar la integridad del código. Así 16 . 2. es igualmente posible identificar el actor responsable de dicha función junto con un conjunto de metadatos asociados a dicha función. organización o sistema) creó. su corrección con respecto a unas determinadas especificaciones. debe aclararse que el modelo se centra en los actores. el proceso completo puede ser chequeado si cada actor firma su acción. Lógicamente. el éxito de cada uno de los pasos es determinante para continuar con el proceso. generó. implicará la participación de otros actores como son las Entidades certificadoras que emiten los certificados de cada uno de los actores. sino por ejemplo un dispositivo físico o lógico. la identidad (contrastada por algún medio.4. o incluso. proporcionó. Como consecuencia. según la política 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. Por otro lado.3. a su vez. Con posterioridad. PSC y PSC-Cert Nuestro modelo permite identificar con claridad quién realiza cada una de las funciones básicas en la ejecución del código. sus relaciones. en cada paso se generan los correspondientes metadatos de cada una de las acciones firmados por el actor de la acción correspondiente. Es responsabilidad del cliente (que es quien usa el código y quien determina o difunde la política aplicable) aceptar o no aquellas circunstancias en las que las excepciones son subsanables a posteriori. Por ejemplo.En cualquier caso.

Por ejemplo. esencialmente por las variaciones respecto a los siguientes aspectos: Los roles asumidos por cada uno de los actores. el contenido final de los metadatos firmados viene determinado por las políticas y/o contratos entre consumidor y proveedor (§ 2. una para el código fuente y otra para el código compilado. En el apartado § 2.4). producción y ejecución del código.. En cualquier caso.9). compilado. Así mismo distinguiremos dentro de PSC dos partes: el código en sí mismo potencialmente representado en diversos formatos (fuente. organizaciones o sistemas hardware o software. De este modo. generalmente XML 17 .10).. 1 Se usa el operador + con el significado de “agregación” de las distintas partes expresadas en modo textual. suministrado (suministrador). al final del proceso podemos obtener un código cualificado como “seguro” puesto que no sólo ha sido creado (autor). Es decir. o una combinación de diferentes tipos de actores en una misma arquitectura. puesto que incluye información que lo hace seguro y portable. esta separación permitirá que un tercero pueda comprobar la seguridad de un código sin que dicho código sea revelado.4.2 se aborda con más detalle la implementación de este tipo de certificados. Los distintos tipos de actores implicados en el proceso. verificado (validador) y generado (compilador) por entidades identificadas y de confianza. si son personas. un cliente puede asumir el rol de un suministrador o un autor (cuando existe autoproducción de código). Denominaremos al código producido de esta manera PSC (Portable Secure Code). No obstante.11.por ejemplo. sino que dichas acciones vienen acompañadas por metadatos que permiten su comprobación por un tercero fuera del círculo de confianza creado entre los actores. pero pueden existir más). P SC (C ) = C + P SC -cert(C ) (2. existen dos acciones de validación. Variaciones al flujo del proceso de creación. Los distintos modos de aplicar las políticas establecidas y acordadas entre las partes. Como puede observarse. A partir de WSbSC-RM pueden definirse arquitecturas concretas (que etiquetaremos como WSbSC) y que son conformes a WSbSC-RM (ver § 2. el modelo puede en efecto dar cabida a una gran variedad de escenarios. debe tenerse en cuenta que para el código pueda ser considerado como seguro el flujo debe incluir al menos una acción relacionada con la validación del mismo (en el modelo general descrito.) y un conjunto de información denominada PSC-cert (certificado de PSC) que contiene toda la certificación necesaria (metadatos firmados) para asegurar que el código es seguro 1 . el código resultado de la compilación realizada por el generador puede venir acompañado de metadatos firmados relacionados con la compilación.1) Como veremos más adelante en una primera aplicación del modelo (§ 2.

Consideremos una entidad consumidora de un servicio ofrecido por una determinada entidad proveedora.4. datos y mensajes) se incluya la seguridad el código. Así por ejemplo. 2. con el fin de ilustrar la aplicación del WSbSC-RM a determinados escenarios de interés. el consumidor puede exigir que el proveedor use WS-Security [29] como estándar para garantizar la confidencialidad e integridad de los mensajes intercambiados. Nuestra propuesta es aplicar WSbSC-RM para que además de los niveles de seguridad ya conocidos (comunicaciones. Para ilustrar este escenario.4. materializando dicho acuerdo en un contrato. Aplicación de WSbSC a la Implementación de Servicios Web Una de las aplicaciones más interesantes del WSbSC-RM es la implementación de servicios web. representado en la Figura 5. Este nuevo escenario. analizaremos con más detalle algunas de estas arquitecturas WSbSC.Figura 5: Implementación de Servicios mediante WSbSC En las siguientes secciones. la expresión de esta política de seguridad se expresa generalmente mediante un conjunto de estándares tales como WS-Policy [41]. Siguiendo las directrices de SOA-RM y WSA. Adicionalmente ambas entidades pueden acordar una política para sus relaciones mediante servicios web. sería el siguiente: 18 . Nuestro objetivo será obtener una arquitectura WSbSC genérica que permita añadir un nivel de seguridad adicional centrada en el código a cualquier interacción mediante Servicios Web. Dentro de la WSA. tanto la entidad consumidora como la entidad proveedora pueden establecer de forma independiente sendas políticas de seguridad sobre cómo usar u ofrecer el servicio respectivamente. entendiéndose que para usar un servicio elegirá sólo aquellos proveedores del mismo que cumplen su política de seguridad. supongamos que es la entidad consumidora quien establece una política sobre las medidas de seguridad que deben ser soportadas por los proveedores de los servicios que desea usar. WS-PolicyAttachment [40] y WS-SecurityPolicy [28].

mediante los cuales podrá obtener el PSC-cert de dicha implementación y el resultado del proceso. si no lo ha hecho anteriormente. La figura 6 muestra una visión general y permite comparar los tres escenarios básicos de intercambio de información entre una entidad consumidora y proveedora. Modelos de intercambio de información con WSbSC En la sección anterior se ha analizado la aplicación del modelo de referencia de WSbSC donde sólo una de las entidades (típicamente el proveedor de un servicio) obtiene el PSC-cert y el código no viaja necesariamente entre proveedor y consumidor. Si suponemos que tanto la entidad consumidora como la proveedora confían en el validador. nos permitirá extender el modelo de una forma natural y consistente hacia el concepto de objeto portable y seguro. cuáles son los métodos de verificación empleados por el validador del proceso. entonces la entidad consumidora podrá solicitar la validación del código al validador. El primer caso (a) es el clásico (SOA-RM [25]): ambas entidades sólo inter19 . La interacción descrita admite diversas variaciones algunas de ellas con portabilidad del código pero manteniendo nuevamente la premisa de que la entidad consumidora no conozca el código sino su nivel de seguridad . Así por ejemplo. tal como SOA-RM y WSA han indicado que ocurre típicamente (§ 2. A continuación describiremos un tercer escenario bastante más complejo en el que ambas partes (consumidor y proveedor) deben hacer uso de PSC-cert para que se cumplan sus respectivas políticas de seguridad. 2. analizarlo y evaluar su validez. según la política de la entidad consumidora. no sería necesario (ni deseable) puesto que el PSC-cert (aisladamente) permite que el consumidor pueda confiar en la seguridad del código sin conocer dicho código. etc. la entidad proveedora podría enviar al consumidor una copia del código cifrada con la clave pública del validador. Así por ejemplo podrá verificar si cada uno de los actores son entidades de confianza.(I) la entidad consumidora solicita un servicio de la entidad proveedora. la entidad proveedora. Uno de los aspectos importantes de esta arquitectura es que aunque la aplicación de WSbSC-RM permitiría que la entidad consumidora y proveedora también intercambiasen el código incluido en el PSC (facilitándose la portabilidad del código). (II) la entidad proveedora devuelve a la entidad consumidora el resultado del proceso junto con el PSC-cert. Sin embargo. que será comprobado por ésta examinando si cumple los requisitos de seguridad que su política establece. Si es así. ejecutará la implementación del servicio siguiendo los pasos (0 a 9 en la Figura). Pruebas periódicas de validez y el uso alternativo y simultáneo de diferentes validadores de confianza pueden incrementar aún más el nivel de seguridad exigido al código. comienza la interacción enviando un mensaje con los datos de entrada necesarios para que la entidad proveedora realice el servicio. La confidencialidad del código está garantizada por el cifrado y la clave pública del validador garantizará que sólo éste puede descifrar el código. Su política de seguridad establece que dicha entidad proveedora debe soportar código seguro mediante WSbSC.3. Este nuevo escenario.5.1). antes de procesar el servicio.

El segundo caso (b) se corresponde con el escenario básico descrito en § 2. En definitiva. aunque internamente ambas entidades realizan un proceso y mantienen estados privados. Métodos : conjunto de las únicas operaciones autorizadas para acceder o modificar el estado de un objeto. nuestro objetivo será extender WSbSC-RM para su aplicación en objetos [26]. Un objeto es algo más que una combinación de estado y métodos.Figura 6: Modelos de intercambio de información basados en WSbSC-RM cambian datos (generalmente contenidos en mensajes). se intercambia código y estado y se obtienen certificados de ambos (código. y código + estado). Según la teoría clásica de orientación a objetos hay dos aspectos que merecen ser resaltados: 20 . y para centrar el problema. El tercer caso. SOA-RM establece que también existe un estado como “efecto de la vida real” compartido entre ambas. muestra el escenario más genérico en el que se comparte proceso. Como hemos visto. Como referencia. Estado : conjunto de valores de los atributos de un objeto en un momento dado.4 donde generalmente el código no es revelado pero se obtiene un certificado del mismo (PSC-cert) que permite hacer uso de una política más completa de seguridad incluyendo el código. partimos de los siguientes conceptos OO: Objeto : entidad que tiene un estado que sólo puede ser accedido o modificado por las operaciones y servicios asociados con él. La entidad consumidora entrega unos datos de entrada y la proveedora devuelve eventualmente unos datos de salida o resultado.4. cuyo detalle describiremos en los apartados siguientes.

independientemente de los distintos modos para realizar y reutilizar tal vinculación (clases. Los cambios de estado sólo pueden ser producidos por la ejecución de los métodos del objeto. Como veremos más adelante. las clases pueden heredar estructura y código de otras clases mediante un mecanismo conocido como “herencia”. una clase permite compartir la estructura del estado y el código de los métodos de todos los objetos creados a partir de la misma. Para nuestro estudio nos centraremos únicamente en el concepto de objeto como encapsulación de estado y métodos. puedan realizarse clasificaciones de objetos o réplicas de objetos dando lugar a que un mismo método pueda serlo de dos objetos diferentes o un estado pueda ser transformado a distintas representaciones normalizadas. desde nuestro modelo. El concepto de objeto conlleva la no separación entre sus atributos y los métodos que los manejan. Además. clonación. en principio.1. La existencia de un atributo no tiene sentido si no se refiere a un objeto. aunque esto podría ser posible con determinados mecanismos (como el de “delegación” [24]). En los apartados siguientes. Como veremos más adelante. un prototipo parece más adecuado en ámbitos no centralizados (relaciones distribuidas entre iguales). analizaremos cómo puede obtenerse un nivel de 21 . tanto uno como otros pueden ser analizados de manera independiente con el fin de que objetos con características y/o comportamiento similares puedan ser clasificados y reutilizados. por ej. No obstante. Se dice que un objeto encapsula su estado y sus métodos. clásicamente se han utilizado dos conceptos: Clase : Permite definir un “contenedor” para objetos que tienen la misma estructura y cuyos métodos son los mismos. Para realizar estas clasificaciones. En definitiva. entendiéndose que ambos conceptos son aplicables en función del contexto. 2. En definitiva. un método de un objeto en sí mismo no tiene sentido si no es como parte del objeto al que pertenece. De la misma forma. los conceptos de clase y prototipo deberán ser tenidos en cuenta en una posterior implementación del modelo. el punto más importante es que el estado tiene asociados un conjunto de métodos permitidos y el resto de operaciones no incluidas en dicho conjunto de métodos tienen prohibido el acceso o modificación del estado. herencia. La principal diferencia con respecto al enfoque de clases es que en este tipo de soluciones el objeto no necesariamente cambia sus métodos cuando son modificados los métodos del objeto a partir del cual fue “clonado”. aunque con el importante matiz de que los objetos se crean mediante réplica de un protopipo que contiene “ranuras” (slots) que pueden ser atributos o métodos. sin perjuicio de la necesaria vinculación entre estado y métodos. Prototipo : El concepto es similar. Así por ejemplo. delegación). lo anterior no es óbice para que tanto estado como métodos puedan ser representados de forma independiente o para que. mientras que por el contrario el mantenimiento de clases parece más indicado en ámbitos centralizados donde una organización controla y supervisa de manera asimétrica la definición de clases de objetos.

en este escenario. En este caso los requisitos de seguridad son más complejos puesto que el consumidor y el proveedor quieren asegurarse no sólo de que la implementación del servicio es segura (como en el caso (b) de la Figura 6) sino también que las interacciones entre los objetos de entrada y la implementación del servicio son seguras. ambas entidades intercambian además de datos. La entidad consumidora solicita un servicio de la entidad proveedora y cómo la información de entrada proporciona uno (o varios) objetos de entrada. WSbSS: Estado seguro basado en Servicios Web En el tercer caso (c) de la Figura 6 puede verse la interacción básica entre dos entidades usando objetos en comparación con los casos (a) y (b). código pues los objetos de entrada y de salida tiene asociados unos métodos implementados mediante código y ambos viajan entre consumidor y proveedor. en esta situación es necesario extender el concepto de PSC-cert para su aplicación en objetos. si no lo ha hecho previamente. La entidad proveedora realiza el servicio interactuando internamente con los objetos de entrada (mediante sus métodos). 22 . Como puede deducirse. puesto que los códigos de M1 y M2 van a ser recibidos por el entorno de ejecución de B. obtiene un resultado que eventualmente también puede ser un objeto y lo devuelve a la entidad consumidora. 2. 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 métodos M1 y M2 conforme a la política establecida por B. De una manera análoga. En primer lugar.Figura 7: Objetos seguros y portables con WSbS* seguridad sobre un objeto (entendido tal como lo hemos definido) desde la perspectiva de WSbSC-RM. La aplicación de WSbSC-RM permitirá garantizar la seguridad de este código portable. veamos un ejemplo. que se representa en mayor detalle en la Figura 7.6. tendremos que A. Para describir este caso con mayor profundidad.

5) pero con las características siguientes: Puede ser portable Puede ser transformado para obtener una representación en un formato diferente sin que el significado de la información que representa se vea afectado. el cual sólo puede ser accedido mediante sus métodos (por ejemplo. Suministrador: opcionalmente. 23 . el propietario de esos datos (el estado de la Agenda en un momento dado) es dicha persona. Para entender mejor este concepto. transformado y verificado. distinguimos los siguientes actores: Propietario: es el dueño de la información representada por el estado.2: P SC (M1 ) = C (M1 ) + P SC -cert(M1 ) P SC (M2 ) = C (M2 ) + P SC -cert(M2 ) (2. En este caso. de forma análoga a como fue estudiado para el código (§ 2. consideremos por ejemplo el objeto “Agenda” cuyo estado es el conjunto de datos de contacto de una determinada persona.3) B recibe los códigos de M1 y M2 mediante P SC (M1 ) y P SC (M2 ).2). etc. En este caso. A y B podrían acordar que el estado (portable) tenga un nivel de seguridad equivalente al que tiene el código. corrección. En este caso. borrar o modificar una cita). 2. el propietario puede delegar en este actor la acción de ceder el estado a un tercero para su distribución o uso. al igual que el código puede ser externamente suministrado. Entre los servicios que puede ofrecer se encuentra la cesión a un suministrador. De esta forma. carga y transformación puede ser realizada de forma remota pero aplicando unas condiciones mínimas de seguridad previamente acordadas Puede ser verificado para comprobar determinados aspectos como integridad. compilado y validado. y siguiendo igualmente las políticas y/o contratos que habrán de establecer o acordar previamente A y B. el estado podrá ser externamente suministrado. En definitiva.1.4. B admitirá la entrada de este código en su entorno puesto que lleva asociado un certificado de seguridad representado mediante PSC − cert(M1 ) y P SC − cert(M2 ). PSS y PSS-cert En este punto. Introduciremos.2) (2. el concepto central es el estado (§ 2. añadir. Su transmisión.deberá obtener el PSC de ambos siguiendo el modelo de WSbSC descrito en § 2. el concepto de “Estado portable y seguro” (PSS).4.6.

Validador: verifica el estado conforme a unas reglas de validación determinadas (por ejemplo. Observar que las transformaciones de formato son realizadas por actores externos al código y al estado y.Convertidor: opcionalmente. la seguridad de los datos (y más concretamente su empaquetamiento mediante de mensajes) han sido tratados profusamente por los diferentes estándares de seguridad en servicios web. Así. de la misma forma que puede ser comprobada la integridad. la corrección y la consistencia de un determinado código. Así por ejemplo. A diferencia de lo estudiado hasta ahora. generación de formato con características especiales. etc. puesto como ya observamos. Por otro lado. Esto nos lleva a afirmar que el interés de aplicar el mismo modelo a ambas partes (estado y código) no sólo se deriva de los beneficios obtenidos para cada una de ellas sino también de los beneficios de las deducciones obtenidas como consecuencia de relacionar código y estado. o estado (reglas de integridad de datos) este análisis de integridad de código y estado. al igual que un código compilado debe tener el mismo comportamiento y debe ser “equivalente” al código fuente. será externo al objeto en sí y está asociado al entorno en el que se ejecuta. No obstante. en principio podría parecer innecesario añadir un nivel más de seguridad. eso no es óbice para que la seguridad del estado sea tratada de forma independiente. ya hemos aclarado que aunque estado y métodos son “inseparables” en el sentido de que sólo los métodos permitidos permiten el acceso y modificación del estado. cualquier anomalía puede escapar del conocimiento de los autores y propietarios de código y estado. en el caso concreto de un estado (asociado a unos métodos) la aplicación de la dualidad dato-programa al caso del estado es interesante porque permite modelar el estado de la misma forma que se modela el código. un dato representado con un lenguaje de “alto nivel” como XML (análogo a los lenguajes de programación de alto nivel con una gramática legible por su cercanía a la gramática del lenguaje natural) también debe ser equivalente a un dato transformado (compilado) en un formato de más bajo nivel. si no se tienen en cuenta dichas transformaciones. Entre los servicios ofrecidos por el convertidor o transformador del estado se encuentran: optimización (en tamaño por ejemplo). a diferencia de las técnicas de integridad de código (por ej. lo mismo puede hacerse para el estado. según reglas de integridad de la información). invariantes). puede ser necesaria la conversión del estado desde un formato a otro formato. el estado es un “dato” y por tanto. Debe recalcarse que. de manera análoga a como el código compilado es equivalente al código fuente. Dicho de otro 24 . aunque podrá basarse en técnicas análogas. se entiende que aquí las relaciones entre los diferentes formatos y transformaciones de código y estado también ayudan a entender mejor los aspectos de seguridad asociados y de ahí su interés en nuestro modelo. El análisis de la integridad del estado. sin que el significado de la información cambie. independiente del análisis de la integridad del código es muy útil para detectar el comportamiento incorrecto de los métodos que acceden y modifican dicho estado. Otro ejemplo de las relaciones entre ambos son las consecuencias derivadas de la obtención de los distintos formatos que el compilador por un lado y convertidor por otro efectúan sobre código y estado respectivamente. Aunque deberá ser objeto de un análisis posterior más exhaustivo.

es suministrado (suministrador). siendo: P SS (S ) = S + P SS -cert(S ) (2.2.4) Nuevamente. Objetos seguros basados en Servicios Web Aproximación a PSO y PSO-cert En este apartado realizaremos una primera aproximación a una arquitectura de objetos seguros basados en Servicios Web. Como ocurre en WSbSC-RM estos actores pueden ser locales o remotos. Por ejemplo. en la Tabla 1 se muestra la dualidad entre código y estado (dato). Como veremos más adelante. la entidad A obtendrá. las cuales pueden generar metadatos con los que construir un certificado de PSS denominado PSS-cert. Consecuentemente.Código Autor Suministrador Compilador Validador Estado Propietario Suministrador Convertidor Validador Cuadro 1: Dualidad Código/Estado entre actores modo. 2. Dualidad Código-Estado A modo de resumen. deberá existir un nuevo actor que se ocupe de validar la relaciones entre código y estado.6. obtendremos un estado cualificado como portable y seguro (PSS) que tiene un propietario. 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 código. Al modelo de referencia de la arquitectura equivalente que permite el intercambio seguro de estado la denominaremos WSbSS-RM (Web Services based Secure State).7. si no lo ha hecho anteriormente. no todas las representaciones o conversiones del estado pueden ser compatibles con las transformaciones (compilaciones) del código.7. transformado (convertidor) y verificado (validador) por entidades identificadas y de confianza. 2.1. 2. debe ser posible detectar si un código malicioso modifica directamente el archivo o la memoria donde se almacena un estado transformado o un código compilado). el cual indicará y permitirá a B asegurarse de que dicho estado junto con sus métodos son seguros según el enfoque WSbSC y WSbSS.La aplicación de WSbSC y WSbSS 25 . un cambio de formato realizado por el “entorno de ejecución” del objeto no es un “método” de ese objeto y por tanto aunque se vigile la encapsulación de métodos-estado. Siguiendo con la interacción en el escenario de la Figura 7. un ataque a la integridad del estado (o el código) transformado por el entorno de ejecución podría quedar fuera del estudio de la seguridad si no se aplica el modelo propuesto (ej. esta separación permitirá que un tercero pueda comprobar la seguridad de un estado sin que dicho estado tenga que ser revelado a un tercero. el PSS(S).

Se entiende que el objetivo final es que tanto A como B puedan tener confianza entre sí: A porque no puede permitir que los métodos M1 y M2 sean ejecutados en un entorno que no sea de confianza (puesto que en ese caso podría comprometerse el objeto en sí) y B porque tampoco puede permitir que se ejecuten en su entorno de ejecución operaciones que puedan suponer un riesgo al ser ejecutadas. 26 . B tendrá que obtener un PSO-cert correspondiente a su entorno de ejecución. código de las operaciones M1 y M2 .6) (2.7) (2. B podría alterar tanto su propio estado (accedido y/o modificado por la implementación del servicio) como el estado del objeto O1 . pero cuyo código compilado. así como los certificados de estos elementos.4 para un escenario WSbSC. además del P SO − cert(O1 ) enviado de A a B. En este punto. procesador y verificador y por tanto. tales como por ejemplo que el entorno de B sea compatible con el código compilado por el compilador en A. También hay casos intermedios. en ese caso el P SO − cert(O1 ) en el entorno de B es formalmente idéntico al de A. Por esa razón. B puede tener diferente suministrador. a través de la implementación del servicio puede hacer uso del objeto O1 y ejecutar sus métodos con el nivel de seguridad que indique P SO − cert(O1 ).conduce de una forma consistente a unas primeras definiciones de objeto seguro y portable (PSO) y certificado de objeto seguro y portable (PSO-cert): n O=S+ i=1 Mi (2. PSS-cert y PSO-cert. A y B utilizarán PSO-certs si así está establecido en respectivas políticas o en contratos de seguridad y consecuentemente ambas entidades confían en los actores que intervienen en la obtención de los PSC-cert. si B comparte los actores que han intervenido en la obtención por parte de A del P SO − cert(O1 ). Por ejemplo.5) (2. Una vez que B recibe P SO(O1 ) tiene tanto el estado. deberá obtener un nuevo PSO-cert de un objeto equivalente a O1 . compilador. que denominaremos O1 . A y B comparten estado (tal como establece SOA-RM) y proceso de una forma segura. suministrado y procesado es diferente del que se obtendría en el entorno de A. verificado. En el otro extremo. tal como se indicó en en § 2. Por tanto. en cuyo caso no sería necesaria transformación alguna por parte de B. Como consecuencia. que en cualquier caso pueden ser modelados usando PSO-certs.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 genérico con estado S y n métodos.4. Aquí se pueden encontrar diversos casos. B. (2.9) Del mismo modo. En nuestro ejemplo: P SO-cert(O1 ) = P SS -cert(S1 ) + P SC -cert(M1 ) + P SC -cert(M2 ).

En ese caso S1 debería estar formateado mediante una estructura que fuese óptima para el acceso secuencial. se muestran los PS*-cert generados en el escenario de la Figura 7. la entidad B deberá obtener el PSC-cert de la implementación del servicio. WSbSO-RM Como indicamos en § 2. En el otro extremo se encuentra el escenario donde tanto A como B tienen entornos de ejecución idénticos y las principales funciones de los PSO-certs serán las de garantizar que las condiciones de ejecución de los objetos en cada entorno no se ven modificadas por ataques o alteraciones que puedan cambiar esa identidad de entornos.4. compiladas. B al estado formateado por el convertidor de B. en realidad B trabaja con una realización 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 ejecución de B con permiso de A. realizar funciones de validación sobre la equivalencia del código y la representación del estado en cada uno de estos diversos entornos de ejecución. B necesita transformar el estado de O1 en un estado equivalente pero que es más óptimo para una interacción que habitualmente ocurre entre A y B. es necesario introducir 27 .9)) ofrecen un nivel de seguridad superior. Aunque los PSO-certs descritos hasta el momento (ecuaciones (2. en función de las políticas establecidas. como por ejemplo el acceso secuencial a una lista de elementos. A modo de resumen. generalmenSi denominamos S1 te los métodos M1 y M2 proporcionados por A pueden no ser adecuados para acceder a dicho estado (no es habitual que la implementación de un método pueda trabajar con distintas representaciones del estado). verificadas y finalmente ejecutadas en el entorno de ejecución de B por sus actores de confianza. junto con su respectivo PSO-cert. un objeto es algo más que una combinación de estado y métodos. A y B podrían acordar que el autor de B realice versiones específicas de M1 y M2 que B B llamaremos M1 y M2 que serán suministradas.8. B deberá reaB lizar el proceso inverso. O1 podrá alcanzar B un nuevo estado S 1 . supongamos que para la interacción entre la implementación de servicio y el objeto O1 . tanto de proceso como de estado ha sido realizado con las garantías establecidas en la política de seguridad aceptada por ambos. Finalmente y para completar el proceso. 2.5. B calcularía el P SO − cert(O1 ). convertir S 1 a la representación original que llamaremos S 1 y devolver O 1 a A. en la Tabla 2. En ese caso. como prueba de que el proceso de conversión/compilación. Acceso legal al estado. A B B B Una vez que B usa O1 a través de sus métodos M1 y M2 . Para la devolución del resultado de B a A. de la misma forma que fue descrito en 2. además de los certificados de objetos obtenidos por A y B. Este último caso ilustra un escenario que permite aplicar el modelo a ámbitos donde se necesita la interacción con objetos en entornos de ejecución heterogéneos y en los que los verificadores correspondientes en ambas partes deberán. y por cuestiones de rendimiento. Es decir.4. es decir.Es interesante resaltar que la identificación de los actores en cada lado y los PS*-cert obtenidos ofrecen garantías en una gran variedad de situaciones. Así por ejemplo.5) a (2.

12]. La necesidad de al menos dos claves de “descifrado” para obtener el estado (al menos una poseída por una operación y otra poseída por el proveedor) sugiere la utilización de técnicas criptográficas basadas en la propuesta de Shamir conocida como “Secret Sharing” [38]. conlleva en algunos casos no sólo una validación de su integridad (ya certificada por el validador del estado mediante PSS-cert) sino también la ocultación del estado de tal manera que sólo pueda ser revelado si se produce la ejecución de una de las operaciones (cualquiera de ellas) y la entidad proveedora en su conjunto tiene autorización para su ejecución.10) Siendo PSMS-cert (Portable Secure Method-State certificate) la representación de los metadatos generados por el validador de la integridad entre estado 28 . La principal función de ese validador es certificar que el estado S no ha sido accedido o modificado por métodos distintos a M1 y M2 .1 podrá realizar otras acciones relacionadas con la consistencia entre el par estado-código. así como diversas soluciones relacionadas con código móvil y agentes móviles. aunque como fue apuntado en § 2. Algunas referencias sobre esta materia pueden ser encontradas en [11.6. Mientras que la seguridad del código y el estado por separado puede ser alcanzada de un modo aceptable en general. Puede observarse que la autorización para acceder o modificar el estado por parte de los métodos. Volviendo al escenario de la Figura 7 puede observarse un nuevo actor validador en el ámbito no de estado o métodos sino del objeto en su conjnto. la seguridad de acceso al estado es un campo menos estudiado y de una complejidad algo más elevada. utilizando técnicas criptográficas de claves simétricas y asimétricas. podemos definir finalmente PSO-cert como: n P SO-cert(O) = P SS -cert(S ) + i=1 P SC -cert(Mi ) + P SM S -cert(O) (2.Cert P SO − cert(O1 ) Quién lo obtiene A (Consumidor) A quién va dirigido B(Proveedor) Para qué se usa Ofrece garantías a B de que la ejecución de los métodos del objeto O1 son seguros Ofrece garantías a A de que el objeto resultante cuyo nuevo estado ha sido obtenido en B es seguro Ofrece garantías a A de que la implementación 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 más de seguridad con el fin de asegurarse de que existen suficientes garantías de que el estado de un objeto sólo es accedido sólo por sus métodos (o versiones transformadas de los mismos) independientemente del entorno de ejecución en el que se encuentre. Independientemente de la técnica utilizada para validar que la integridad código-estado.

la conformidad de una arquitectura concreta con los modelos descritos no es una tarea fácilmente automatizable dado que existe una gran diversidad de posibilidades de aplicación según las implementaciones concretas que se elijan en cada caso. 4. De manera similar. Directrices para la conformidad con WSbS* Una vez descrito el modelo. Tal como indica SOA-RM respecto a su conformidad. el suministrador del código debería ofrecer los servicios mediante servicios web. objeto de investigación [10. PSS-certs y PSO-certs. políticas de confianza. Debe ser posible identificar a todos los actores tal como han sido definidos respectivamente en WSbSC.y métodos. llamaremos WSbSO a las arquitecturas donde se usan los enfoques WSbSC y WSbSS descritos. La seguridad sigue siendo una cuestión abierta en entornos SOA. cabe preguntarse si es posible determinar la conformidad de una determinada arquitectura al mismo. desde un punto de vista conceptual y sin perjuicio de que para caso concretos podría automatizarse la verificación de la conformidad. 21. Esta descripción conformará la estructura de los respectivos PSC-certs.) así como una serie de consideraciones diversas (identidades. 2.1 3. 2. identificando aquellos que se proporcionan mediante servicios web. Modelo de seguridad de WSbS* SOA-RM que sirve como punto de partida de nuestro estudio. WSbSS y WSbSO. Deben poder identificarse alguno de los conceptos que amplían SOA-RM descritos en § 2. Debe existir una descripción concreta de los metadatos asociados a las funciones de cada uno de los actores.10. 6. Debe ser conforme a SOA-RM ([25]. no incluye un modelo de seguridad genérico que permita definir diferentes enfoques de seguridad en las arquitecturas SOA. 33] Por otro lado WSA sí aborda el tema de la seguridad en una arquitectura de servicios web aunque tal como admite en su introducción. Como mínimo.3. etc. pueden distinguirse un conjunto de requisitos básicos de conformidad aplicables a cada uno de los niveles de WSbS* (WSbSC. interacciones 29 . El enfoque de la seguridad según WSA se centra especialmente en la seguridad de mensajes. los mecanismos más habituales de seguridad (autenticación. “no existen especificaciones ampliamente aceptadas sobre seguridad en servicios web”. integridad. las amenazas más habituales a nivel de mensajes. 5.9. autorización. No obstante. líneas 759-778) 2. WSbSS y WSbSO). Debe ser posible la identificación de las políticas y/o contratos con relación a la definición y uso de los PS*-certs. Diremos que una arquitectura es conforme a WSbS* si se cumplen las siguientes condiciones: 1. Deben estar definidos todos los servicios ofrecidos por cada uno de los actores.

Permite abordar la seguridad extremo a extremo no sólo de datos y mensajes sino también del código. Es aplicable a la arquitectura orientada a servicios y a WSbS* 2.11. Es extensible. Con posterioridad a WSA se han realizado propuestas sobre arquitecturas de seguridad en Servicios web [18]. Aunque los diferentes enfoques de seguridad “extremo a extremo” para Servicios web suponen un avance respecto al tradicional método para garantizar la seguridad entre dos puntos (generalmente mediante SSL). Características del modelo de seguridad Las principales características de nuestro modelo son: 1. Las descripciones son genéricas e incluso incompletas (por ejemplo. código. consistente con uno de los objetivos de WSbS*.) Modos de seguridad: son las características de seguridad aplicables en cada nivel 30 .1 nuestro modelo de seguridad puede ser fácilmente implementado haciendo uso de estándares de servicios web. No obstante.extremo a extremo. Se basa en conceptos aplicables a la mayoría de los escenarios reales Nuestro enfoque no propone una solución específica a un problema de seguridad concreto relacionado con servicios web sino que define una infraestructura de seguridad genérica aplicable a una interacción entre un consumidor y un proveedor de un servicio. es compatible con estos modelos de seguridad puesto que permite añadir grados adicionales de seguridad además de los habituales centrados en el mensaje o en el dato. Los conceptos básicos son los siguientes: Niveles de seguridad: se refiere a los sujetos a los que se aplica la seguridad (datos. 2.10. Como veremos en § 2. Veremos que la combinación de estándares y un adecuado modelo de seguridad mejorará la seguridad en la arquitectura SOA. en la mayoría de los casos el foco de atención se ha puesto en el mensaje o en el dato. etc. no es suficiente. la relación entre privacidad y servicios web es explícitamente excluida del estudio)[2]. Nuestra propuesta para un modelo de seguridad.). Con el objetivo de un desarrollo posterior más exhaustivo del modelo. en este apartado se describirá un estudio preliminar de los aspectos básicos que debe contener un enfoque integral de seguridad basado en WSbS*. sobre la cual pueden establecerse políticas concretas. es decir. 3. etc. Se fundamenta en los requisitos básicos de seguridad ampliamente aceptados 5. Puede ser implementado utilizando la tecnología de servicios web 4. sin embargo.1. puede ser mejorado con la introducción de nuevos conceptos 6. es que el modelo de seguridad abarque tanto procesos como datos.

Mensaje : es la unidad básica de información enviada o recibida en una interacción mediante servicios web.10. el mayor grado de seguridad se alcanzará mediante su aplicación progresiva. Objeto: el código como modo de acceso (método) a un estado. 6. Aunque podrían aplicarse cada uno de estos niveles de forma independiente y no exclusiva. él mismo o una certificación del mismo. Este nivel de seguridad aborda la problemática de un proceso en un determinado entorno de ejecución.10. 5.2. En los siguientes apartados se describen estos conceptos en detalle: 2. Dato: los datos que procesa un determinado código son portables y se garantiza la seguridad de extremo a extremo. Modos de seguridad Los modos de seguridad hacen referencia a la mayoría de los aspectos de seguridad clásicos [13]: 31 . Niveles de Seguridad Se distinguen los siguientes niveles: 1. 3.Mecanismos de seguridad: técnicas específicas que permiten alcanzar una determinada seguridad Grados de seguridad: métricas para evaluar la seguridad alcanzada La combinación de cada uno de estos conceptos aplicados a cada escenario concreto permitirá medir el grado total de seguridad de una interacción en un entorno SOA. 4. Para que un sistema sea seguro debe alcanzar al menos un nivel de seguridad. aunque es posible que en un entorno se aplique el nivel 3 y no el nivel 1 o 2. Proceso: el código como fuente de un proceso. desde sus dos puntos de vista básicos: proceso fiable en un entorno no confiable y proceso no fiable en un entorno fiable. 2. Es el modelo generalmente aceptado en una arquitectura SOA realizada mediante servicios web. El código podrá ser tratado como un dato más y por tanto. Aborda la problemática de seguridad asociada no al código o al estado por separado sino a la garantía de que el estado sólo es accedido o modificado por sus métodos y por tanto está prohibido su acceso o modificación directa por parte de otros procesos. Así por ejemplo. Canal: es el medio sobre el cual se transmite la información que intercambian el consumidor y el proveedor del servicio. tal como ocurre con la mayoría de las propuestas de seguridad en Servicios Web. se entiende que un entorno de nivel 3 incluye los niveles 1 y 2. Código: es el código como dato.3. podría viajar entre dos extremos de una forma segura. 2.

Trazabilidad: permite identificar a los actores y la información relativa a las acciones que han realizado para alcanzar algún otro modo de seguridad. En general. otros modos de seguridad pueden ser añadidos. Auditoría: debe existir algún mecanismo para comprobar qué interacciones ha habido con el sujeto objeto de la seguridad. A veces se confunde fiabilidad con los otros modos de seguridad: un código puede ser inseguro no sólo porque un atacante lo haya manipulado (integridad) sino también porque fue escrito incorrectamente por su autor y por tanto no realiza la función a la que estaba destinado. el no repudio requiere la intervención de un tercero de confianza (por ejemplo. Así por ejemplo. 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 cuál están referidos.1. Fiabilidad (o corrección): está relacionado con la corrección respecto a unas reglas determinadas. Nótese que no se consideran identificación y autenticación por separado puesto que se considera que la identificación por sí sola no es segura si no va acompañada por la autenticación. se tiene o se es). Sin embargo. Por ejemplo. Integridad: debe proporcionarse algún medio para garantizar que no ha habido alteración en el sujeto al que se le aplica la seguridad. 4. en el Nivel 1 el modo Integridad está referido a la integridad de datos. 32 . Téngase en cuenta que la identificación cuando está referida a personas no necesariamente es incompatible con la privacidad puesto que existen mecanismos que permiten la “identificación sin revelar la identidad”. 5. 6. sólo pueda realizar las acciones autorizadas. para que un sistema sea seguro deberá aplicar al menos un modo de seguridad. 7. permitiéndose la combinación de diferentes modos. Autorización: debe asegurarse el control del acceso al sujeto protegido de tal forma que. En algunas situaciones no sólo debe proporcionarse Identificación-autenticación sino que también debe poder demostrarse de forma fehaciente que una determinada actuación por parte del sujeto no es posible que haya sido realizada por otro. si el sujeto es el código la fiabilidad implica que la ejecución del código no provoca consecuencias no deseables. Identificación-autenticación: debe proporcionarse algún medio de identificación y autenticación (comprobación de que la identidad mediante alguno de los medios clásicos: algo que se conoce. 2. en general. 8. No repudio: está relacionado con la identidad. 3. Este modo está directamente relacionado con nuestra propuesta de arquitectura WSbS*. Confidencialidad: se evita que el contenido o identidad sea revelado a terceros que no son de confianza. La lista anterior no es completa y por tanto. una entidad de certificación aceptada por las partes) para que sea efectivo.

los sujetos pueden ser a su vez clasificados en otros sujetos. un mensaje. En segundo lugar aparecen los niveles de seguridad definidos que se corresponden con los recursos principales que intervienen en una interacción entre un consumidor y un proveedor para el uso de un servicio. un mecanismo puede proporcionar medios para alcanzar más de un modo de seguridad (por ejemplo.) intervienen diferentes actores que también son sujetos de seguridad. La relación entre modos y mecanismos es de varios a varios.Como hemos indicado en el apartado § 2. es decir. etc. 2. referido a una interacción de servicios [25] lín.5. sobre los cuáles pueden aplicarse modos y mecanismos de seguridad. (Esta definición incluye el concepto de “Contexto de ejecución”. es decir. etc. 2.10.10.4. En cada uno de los niveles de seguridad definidos (canal. los actores del servicio son consumidor y proveedor. Sujetos de seguridad Como hemos visto. y por otro lado. mensaje. la firma electrónica permite identidad-autenticación.10. datos. Los grados de seguridad están relacionados con los sujetos sobre los cuales se aplica la seguridad. mensajes. un modo de seguridad puede ser alcanzado mediante más de un mecanismo. Nótese que cada uno de estos niveles se refiere a sujetos de seguridad que a su vez puede estar compuesto por diversos elementos de manera jerárquica. infraestructuras. En tercer lugar tenemos a los actores que interactuan con cada uno de los recursos (o con los elementos de los que están compuestos). Mecanismos de seguridad Los mecanismos de seguridad hacen posible alcanzar un nivel de seguridad con unos determinados modos de seguridad aplicables.10. Los modos de seguridad aplicables a cada nivel se refieren a éste en todos los elementos que lo forman. etc. según los estándares de Servicios Web está compuesto por una cabecera y un cuerpo. Actores: tal como han sido definidos en § 2 Contextos: conjunto de elementos. 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.5. Por ejemplo. Esta primera clasificación en niveles permite tener una visión general del grado de seguridad alcanzado en los recursos principales.6. actores.2. así como comparar dos o más sistemas para evaluar cuál de ellos obtiene la mayor seguridad con respecto a esos criterios comunes. Cuando un modo de seguridad 33 . 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. Grados de seguridad Un grado de seguridad es una métrica que permite medir de forma relativa la seguridad alcanzada conforme a diferentes criterios. Por ejemplo. integridad y no repudio).

Implementación del modelo La aplicación de los diferentes estándares sobre Servicios Web permiten implementar el modelo para una gran variedad de escenarios. 2.11.se aplica sólo a una parte del nivel se entiende que ese grado de seguridad (aún siendo lógicamente superior a la ausencia de ese modo) está incompleto. Validador. a continuación describiremos brevemente la implementación en el caso particular de WSbSC. Generador y Procesador) deberán ser registrados en un repositorio UDDI 2. Esto permite la localización de cada uno de ellos por parte del resto de los intervinientes.10. Volviendo al escenario de implementación de un servicio web mediante PSC representado en la figura 5. los servicios básicos que ofrecen cada uno de los actores serán: Autor: • requestForCodeTransference : solicitud de derechos para distribuir el código Suministrador: • sendCodeForTransference : envío de un código por parte de un autor para su distribución • requestCode : solicitud de un código por parte de un cliente Validador: • validateCode : petición de validación de un código 34 . Por ejemplo. para el caso de un cliente que soporte el nivel 4 de seguridad. Los actores registran sus servicios básicos en un repositorio UDDI. 17] pueden encontrarse las últimas versiones de los estándares desarrollados por las dos principales organizaciones de estandarización en Servicios Web y SOA: W3C y OASIS). Aunque un desarrollo más detallado de la implementación podrá ser realizado posteriormente con la aplicación de nuestro enfoque a un caso real. ya que la mayor parte de las propuestas se centran esencialmente en el mensaje [32. La asignación de un “peso” por cada aplicación de un modo en los sujetos y sus partes o clasificaciones permitirá obtener un valor cuantitativo (grado) que indicará una mayor o menor seguridad en el conjunto de una manera jerárquica La medida de la seguridad está relacionada con el concepto general de “Calidad de Servicio” (QoS) puesto que se trata de un elemento más en la medición del nivel de calidad en una interacción mediante servicios web. Aunque nuestro principal foco de atención será la implementación de PS*-certs y la descripción del modelo de seguridad que han sido planteado en § 2. 22]. entendiendo que WSbSS y WSbSO se realizan de manera análoga. Suministrador. Cada uno de los actores (Autor. en este apartado vamos a realizar una descripción preliminar del proceso de implementación y los estándares básicos aplicables (en [6. veamos las consideraciones que han de tenerse en cuenta para su implementación: 1. Nuestra propuesta amplía y mejora la medición de la seguridad como un parámetro de la calidad.

El proveedor al recibir la petición del servicio interroga al repositorio UDDI sobre la política de seguridad establecida por el consumidor del servicio o bien obtiene dicha información directamente en el mensaje. o a nivel local mediante cualquier otra tecnología. 6. en un caso general. El consumidor establece mediante WS-Policy [41] y WS-PolicyAttachment [40] la política de seguridad que desea aplicar. rechazar el resultado de la realización del servicio. ofrecidos por los actores mediante servicios web. Obsérvese que tal como se indica en [40]. pero de conformidad con WSbSC el PSC-cert resultante deberá reflejar la identificación de estos actores y los metadatos que se generan por cada una de sus acciones. en su caso.11. si no lo ha hecho anteriormente.9 y tal como se indica en § 2.Generador: • compileCode Procesador: • processCode Y el cliente por su parte deberá ofrecer al menos los siguientes servicios: Cliente: • sendValidatedCode : recepción de un código de un autor para su distribución • sendCompiledCode : envío de código compilado por parte de un generador • sendResults : envío de los resultados del proceso del código Como ya hemos indicado estos servicios pueden ser.1.11. tiene conocimiento del requerimiento de nivel 4 de seguridad que implica la utilización de WSbSC. El consumidor obtiene la descripción WSDL del servicio (probablemente de un repositorio UDDI) y hace la solicitud mediante mensajes SOAP con o sin WS-Security [29] (según la política establecida por el proveedor). podrá. El proveedor envía un mensaje mediante SOAP o WS-Security [23] al consumidor con el resultado del servicio y el PSC-cert de su implementación. la política de seguridad puede estar incluida en el mismo directorio UDDI en el que está registrado el consumidor. 4. en función de su política. 5. El proveedor. 35 . obtiene el PSC-cert de la implementación del servicio (el detalle es descrito en § 2. En función de la política establecida por el cliente podrá aplicar distintos estándares de seguridad a cada uno de los recursos protegidos indicados por la política de seguridad establecida por el consumidor y. En dicha política de seguridad expresada mediante WS-Policy. 7. 3.1). basándose en las directrices del apartado § 2. por su propia política. Si el consumidor no recibe el PSC-cert.

si un mismo actor está realizando varios roles). Sin embargo. 36 . WS-PolicyAttachment [40] define diferentes formas de asociar políticas basadas en WS-Policy WS-SecurityPolicy [28]: aplicación de WS-Policy y WS-PolicyAttachment a WS-Security [23] SAML [7]: permite la utilización de credenciales de identificación. Para la implementación de la descripción de esas políticas se propone la utilización de estándares de seguridad ampliamente utilizados en soluciones SOA y más concretamente en aquellas basadas en Servicios Web. autenticación y atributos de seguridad XACML [27]: facilita la definición de reglas de autorización sobre cualquier tipo de recurso 2. Como puede observarse en la figura 9. Implementación de las política de seguridad El estudio preliminar del modelo de seguridad asociado a WSbS* ha puesto de manifiesto las distintas características de seguridad de deben tenerse en cuenta en cualquier solución basada en WSbS*. la utilización de PS*-certs como medio para reforzar la seguridad a distintos niveles. La implementación típica será una referencia a un documento SAML.2. a que los intervinientes puedan definir políticas de seguridad completas que exijan por ejemplo. estos metadatos (AuthoredCode) están compuestos por las siguientes partes: ActorIdentity: contiene información sobre el actor (Autor en el ejemplo). La implementación de estas características en forma de requerimientos de seguridad permitirá. Fijémonos en el caso concreto de los metadatos generados por el Autor de un PSC. conforme a cada una de sus definiciones.1. CredentialsReference: contiene información sobre las credenciales otorgadas al actor. podemos distinguir una estructura común de PSC-cert.2. PSS-cert y MS-cert.11. Cada uno de los metadatos generados por cada uno de los actores tiene la misma estructura (T_Metadata). A falta de un desarrollo futuro más detallado. un suministrador tiene las credenciales otorgadas por el autor para que pueda suministrar el código en su nombre.11. Implementación de PS*-certs En este apartado analizamos con más detalle la implementación de PS*certs. En la figura 8 se muestra la estructura general de un PSO. Admite una referencia a una entidad UDDI o una referencia a un actor ya definido (por ej. Por ej. tal como ya se ha apuntado. La definición de cada PS*-cert dependerá de las políticas y/o contratos de las entidades consumidora y proveedora. los principales estándares propuestos son los siguientes: WS-Policy [41]: permite definir aserciones genéricas.

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 refiere a los metadatos del actor relacionados con su acción. Por ej. en el caso del autor, incluye nombre del código, licencia, lenguaje de programación, resultado de su acción, etc. SubjectPolicy: es una referencia a la descripción de la política asociada a ese conjunto de metadatos. Por ejemplo, podría incluir una referencia a aserciones WS-Policy. ds:Signature: es un elemento XML-Signature (enveloped) que contiene la firma de todos los metadatos del actor. Típicamente será una firma digital basada en certificados X509. El resto de los metadatos de un PSC-cert (SuppliedCode, CompiledCode, VerifiedCode) generados por los otros actores (Suministrador, Compilador y Verificador) tienen la misma estructura, aunque como se ha indicado la parte “SubjectMetadata” a su vez tendrá una estructura diferente según el actor. Lo anterior se aplica de manera análoga a pss-cert y psms-cert. En el apéndice se incluye un listado completo de un ejemplo de codificación en XML de un PSO.

2.12.

Consideraciones sobre el rendimiento

El modelo descrito ha definido un escenario genérico en el que tal como hemos indicado pueden producirse diversas variaciones que conducen a diversos 38

escenarios, los cuales aún siendo conformes al modelo, son mucho más 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 significativa y por tanto, derivando en un menor rendimiento § 2.11. Aunque un estudio empírico sobre el rendimiento podrá ser realizado junto con la implementación de casos reales, las siguientes consideraciones deben tenerse en cuenta en cualquier análisis sobre rendimiento respecto al modelo: No es necesaria la obtención de PS*-certs en cada interacción entre consumidores y proveedores. Debe entenderse que la implementación del modelo deberá establecer mecanismos para que ambos proveedor y consumidor puedan detectar los cambios que hagan necesaria la obtención de nuevos PS*-certs. Así por ejemplo, sería necesaria en el caso de nuevas versiones del código, cambios en la identidad de los actores, etc. Por otro lado, mediante mecanismos como las sesiones puede conseguirse que la obtención de esa información sólo sea necesaria al principio de una interacción. A este respecto, existen algunos estándares como que abordan este aspecto [9, 8]. Los roles de los diferentes actores del modelo pueden ser realizados por la misma entidad, simplificándose por tanto la generación de los metadatos contenidos en los PS*-certs. Por ejemplo, una misma entidad de certificación puede realizar el rol de validador de código, estado, y objeto, tanto en la parte de la entidad proveedora como consumidora (asumiendo que ambas entidades consideran de confianza a dicha entidad de certificación). El modelo establece que todos los actores deben ser identificados a los distintos niveles (código, estado y objeto), salvo aquellos indicados como opcionales. Sin embargo, en determinados escenarios y determinados actor no tiene por qué ser una organización o persona ofreciendo sus servicios mediante Servicios Web (§ 2), sino que puede ser un componente hardware [16]. En este caso, la representación de PSC-certs podrá tomar una forma más compacta. En los últimos años 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 código en el contexto de la arquitectura orientada a servicios y más específicamente 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 sólo será posible alcanzar un nivel adecuado de seguridad si los mecanismos de protección tratan no sólo los datos sino también el código que los gestiona

39

La primera conclusión es que es posible compatibilizar un modelo genérico como es la arquitectura de referencia SOA con los conceptos que aparecen en el estudio de la seguridad del código, puesto que el código también 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 más complejas. En este trabajo se presenta la aplicación del modelo a un caso de gran interés como es la implementación de un servicio en un escenario genérico. Posteriormente, el modelo concebido inicialmente para el código se amplía y extiende para tratar con la misma filosofía (y teniendo en mente la conocida dualidad dato-programa), el problema de la seguridad del estado y de un objeto entendido como la encapsulación de código y estado. Será necesario profundizar un poco más en el modelo completando algunos aspectos que sin duda aparecerán en la aplicación 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 código móvil y los agentes móviles. Esto podrá poner a prueba, aún más, 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á añadir valor al modelo y, sobre todo, puede permitir la aplicación con un enfoque más actual de algunas técnicas de algún modo relegadas (e incluso olvidadas), a ámbitos muy específicos. Como segunda conclusión, podemos afirmar que uno de los puntos centrales de la propuesta ha sido la introducción del concepto de PS*-cert y en el presente trabajo se ha realizado una primera aproximación a su implementación mediante XML, basándose en conocidos estándares como UDDI, SAML, WS-Policy o XML-Signature. La introducción de otros estándares para tratar diversos aspectos que indudablemente aparecerán en la aplicación de un caso real, es un trabajo futuro que por sí mismo supone una gran complejidad. Relacionado con esto último, la complejidad de los estándares, su compatibilidad, el establecimiento de modos básicos de interoperabilidad entre los mismos (“profiles”) así como la propia naturaleza dinámica y evolutiva de los estándares (continuamente aparecen nuevas versiones y nuevos estándares) influye en que el resultado final de los lenguajes propuestos ya puede adivinarse complejo. En la aplicación práctica del modelo nos encontraremos con el problema del rendimiento, crucial si se desea que dicha aplicación práctica sea además aplicable a casos reales. Siendo un objetivo central del trabajo futuro precisamente esa aplicación efectiva a casos reales. En este sentido, se ha realizado una primera aproximación al problema del rendimiento con algunas indicaciones de cómo puede mejorarse en casos reales. No obstante, esto es un problema general que afecta a cualquier solución basada en SOA (y más concretamente en servicios web) para el cual ya están apareciendo propuestas de optimización, al igual que ocurrió en su día con la propuesta de máquinas virtuales Java, cuyo rendimiento evolucionó de forma positiva en el tiempo hasta convertirse en una tecnología muy extendida, sin problemas de rendimiento en su aplicación real. En tercer lugar, otro aspecto abordado en este trabajo que requerirá un desa40

al contrario de lo que podría suponerse. La mayor dificultad 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 código sobre SOA) y también relacionado con muchos trabajos anteriores (por su carácter de modelo de referencia). proceso y la combinación de ambos (objeto). La principal aportación de esta primera aproximación al modelo de seguridad es la distinción entre distintos niveles de protección incluyendo el nivel de datos. aunque no por ello menos interesantes. puede sentar las bases de otros trabajos más específicos. en apariencia sencillos. mayor complejidad que el desarrollo de soluciones a problemas muy concretos. se propone el estudio de una solución basada en técnicas de “Secret Sharing”. cuyas bases han sido descritas en una de las secciones. Podría afirmarse como última conclusión que el estudio de modelos de referencia. El presente trabajo por tanto. código.rrollo futuro es la efectiva definición de un modelo de seguridad asociado a la propuesta. y tal como se ha indicado. Sobre este último nivel. puede conllevar. 41 .

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

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

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

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

Actor : Persona u organización 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 envía y recibe mensajes y que actúa en nombre de una persona y organización. en el que el acceso se proporciona por una interfaz normalizada y cuyo uso es ejercido consistentemente mediante restricciones y políticas especificadas en la definición del servicio.Apéndice A Glosario Servicio : Mecanismo que permite el acceso a un conjunto de una o más aptitudes. Mensaje : Es la unidad básica de los datos enviados por un agente de servicio a otro agente en el contexto de Servicios Web Política : (en el contexto de servicio): Una política representa las restricciones en el comportamiento de un agente cuando realiza acciones o acceso a recursos. 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. Una política también puede estar referida al comportamiento de actores. Una política debería estar representada por cada uno de los siguientes aspectos: Aserciones : sentencias que describen una determinada restricción asociada a una política. 46 . en este caso las restricciones no se traducen de manera exclusiva en restricciones sobre el comportamiento permitido de los agentes que actúan en nombre de tales actores. Existen dos tipos básicos 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.

Puede ser una autoridad externa a las partes. Concreta : implementación específica de una solución basada en arquitecturas de referencia. Vigilante de política : actor responsable del cumplimiento de la política. sistema. administrador. los contratos implican acuerdos entre varias partes. de un contrato Principios básicos de seguridad : Mínimo privilegio : Es el principio de seguridad fundamental: Cualquier sujeto (usuario. Normalmente es el propietario. Dominio : es un conjunto identificado de agentes y/o actores que aceptan y por lo tanto están sujetos a las restricciones de una política. de una política. Partes : son el conjunto de actores que aceptan las cláusulas del contrato. 47 . programa. Vigilante de contrato : actor responsable del cumplimiento de un contrato. De manera análoga a una política. un contrato debería estar representado por cada uno de los siguientes aspectos: Cláusulas : son las aserciones de un contrato. Guarda de política : mecanismo que asegura (fuerza) el cumplimiento de una política. etc) debe tener sólo los privilegios que necesita para realizar las tareas que tiene asignadas. Descripción de política : es la representación en un lenguaje formal y/o no formal. tecnologías. Arquitectura : De referencia : estructura que ofrece una solución abstracta a un problema en un determinado dominio. implementaciones y otros detalles concretos. Guarda de contrato : mecanismo que asegura (fuerza) el cumplimiento del contrato. axiomas y relaciones dentro de un determinado dominio y que es independiente de estándares específicos. Descripción de contrato : es la representación en un lenguaje formal y/o no formal. patrones y requisitos adicionales. Mientras que una política está asociada con el punto de vista de un actor individual.Propietario de política : es el actor que define y posee una determinada política. incluidos los que vienen determinados por el entorno tecnológico. Contrato (en el contexto de servicio): Un contrato representa un acuerdo entre dos o más actores. Modelo de referencia : conjunto mínimo de conceptos. Este conjunto forma un modelo abstracto que permite comprender las principales relaciones entre las entidades de un entorno y el desarrollo de arquitecturas específicas que usen estándares o especificaciones aplicados a este entorno.

48 . No obstante. Punto de choque : Obligar al atacante a usar un canal de entrada que pueda monitorizarse y controlarse. 2) La complejidad proporciona todo tipo de posibilidades para el hallazgo de puntos débiles. un sistema debe ser tan simple como sea posible pero no más. nunca debe comprometerse la seguridad por la simplicidad. Simplicidad : La simplicidad es un principio de seguridad por dos razones: 1) Si algo es más fácil de comprender también es más fácil de proteger.Múltiples niveles de defensa : No basar toda la seguridad en un único mecanismo. No puede protegerse algo que no se comprende. Punto débil : La seguridad de un sistema es siempre la de su elemento más débil. Instalar múltiples mecanismos de seguridad que actúen en caso de fallo de los demás Diversidad de defensas : No sólo son necesarios distintos niveles de defensa sino también distintas clases de defensa.

ds:Signature) han sido simplificadas para facilitar la legibilidad. 49 . Figura B.1: Ejemplo de PSO-cert Se ha supuesto también que la validación en todos los niveles (PSC. Se supone que dicho objeto sólo tiene dos métodos: AddAppointment y DeleteAppointment. Algunas secciones de la representación XML (por ej. No obstante. La estructura general del PSO-cert está representada en la Figura B.1. PSS y PSMS) es realizada por el mismo Validador.Apéndice B Ejemplo de codificación en XML de PS*-certs Este apéndice describe la representación XML simplificada de PSO correspondiente al un ejemplo de objeto denominado “MyPersonalPlanner” (agenda para planificación personal de tareas). el código ha sido comprobado sintácticamente (Wellformed) y gramaticalmente (Validated) conforme a su XML-Schema.

</wsbs:Code> <wsbs:Code wsu:Id="compiled:MyPersonalPlanner:AddAppointment" EncodingType="Base64"> CByZXR1cm4gKGNlbHNpdXMgKiA5IC8gNSk...... </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. PSO-Cert.0. </wsbs:Code> <wsbs:Code wsu:Id="compiled:MyPersonalPlanner:DeleteAppointment" EncodingType="Base64"> kOld9kI83F45HbgHugLXu80d." xmlns:uddi="urn:uddi-org:api_v3" xmlns:wsu="http://docs.w3. </wsbs:CurrentState> </wsbs:s> </wsbs:o> <wsbs:pso-cert wsu:Id="pso-cert:MyPersonalPlanner"> <wsbs:psc-cert wsu:Id="psc-cert:MyPersonalPlanner:AddAppointment"> 50 .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.w3.xsd"> <wsbs:o wsu:Id="o:MyPersonalPlanner"> <wsbs:method wsu:Id="psc:MyPersonalPlanner:AddAppointment"> <wsbs:Code wsu:Id="source:MyPersonalPlanner:AddAppointment" EncodingType="Base64"> cHVibGljIGNsYXNzIENvbnZlcnRlcg0Kew0KICBwd.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.org/ns/ws-policy" xmlns:xsi="http://www. </wsbs:Code> </wsbs:method> <wsbs:method wsu:Id="psc:MyPersonalPlanner:DeleteAppointment"> <wsbs:Code wsu:Id="source:MyPersonalPlanner:DeleteAppointment" EncodingType="Base64"> Ji98cfHwsHHycsYs0IdT5N7bhwpP2Vejg5BY1o9i.org/2001/XMLSchema-instance" xsi:schemaLocation="...xsd" xmlns:wsp="http://www...0" encoding="utf-8"?> <wsbs:pso wsu:Id="pso:MyPersonalPlanner" xmlns:wsbs=".oasis-open.

w3..com:sw:05a1"/> </wsbs:ActorIdentity> <!--Actor credentials--> <wsbs:CredentialsReference URI=". </wsbs:VersionHistory> </wsbs:Result> </wsbs:SubjectMetadata> <wsbs:SubjectPolicy> <wsp:PolicyReference 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=".0</wsbs:Version> <wsbs:License wsbs:licenseType="GPL">./MyPersonalPlannerPolicy#AddAppointment:AuthoredCode" > </wsp:PolicyReference> </wsbs:SubjectPolicy> <ds:Signature xmlns:ds="http://www.org/2000/09/xmldsig#sha1"/> <ds:DigestValue>AjPpVHwLzJS6AALuTU90oDvaUWo=</ds:DigestValue> 51 .w3...org/2001/10/xml-exc-c14n#"/> </ds:Transforms> <ds:DigestMethod Algorithm="http://www.xsd"/> <wsbs:Version>1.w3.org/2000/09/xmldsig#"> <ds:SignedInfo> <ds:CanonicalizationMethod Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/> <ds:Transform Algorithm="http://www...org/2000/09/xmldsig#rsa-sha1"/> <ds:Reference URI="#psc-cert:MyPersonalPlanner:AddAppointment:AuthoredCode"> <ds:Transforms> <ds:Transform Algorithm="http://www.</wsbs:License> <wsbs:Result> <wsbs:ActionTime>2007-05-02T09:45:00Z</wsbs:ActionTime> <wsbs:VersionHistory> <wsbs:VersionDescription wsbs:VersionNumber="1.0"> Initial </wsbs:VersionDescription> ...w3.org/2001/10/xml-exc-c14n#"/> <ds:SignatureMethod Algorithm="http://www..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./MyPersonalPlanner.w3..AddAppointment.

.com:sw:05a2"/> </wsbs:ActorIdentity> <!--Actor credentials--> <wsbs:CredentialsReference URI=".C=ES </X509IssuerName> <X509SerialNumber>1014886138</X509SerialNumber> </X509IssuerSerial> <X509Certificate> MIIFRTCCBK6gAwIBAgIEPH3u+jANBgkqhkiG9w0BAQUF.. </ds:SignatureValue> <KeyInfo> <X509Data> <X509IssuerSerial> <X509IssuerName> OU=FNMT Clase 2 CA./MyPersonalPlannerPolicy#AddAppointment:SuppliedCode" > </wsp:PolicyReference> </wsbs:SubjectPolicy> <ds:Signature xmlns:ds="http://www... </X509Certificate> </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.....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.org/2000/09/xmldsig#"> .O=FNMT.... 52 .w3. <ds:Reference URI="#psc-cert:MyPersonalPlanner:AddAppointment:SuppliedCode">...../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=". </ds:Reference> .

w3..</ds:Reference> .. <ds:Reference URI="#psc-cert:MyPersonalPlanner:AddAppointment:CompiledCode"> ..../MyPersonalPlannerPolicy#AddAppointment:CompiledCode" > </wsp:PolicyReference> </wsbs:SubjectPolicy> <ds:Signature xmlns:ds="http://www..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=". </ds:Signature> </wsbs:CompiledCode> <!--metadata added by verifier--> <wsbs:VerifiedCode wsu:Id="psc-cert:MyPersonalPlanner:AddAppointment:VerifiedCode"> <!--Actor identity metadata--> <wsbs:ActorIdentity wsu:Id="MyPersonalPlanner:Verifier"> <wsbs:VerifierReference uddi:businessKey="uddi:sf../saml-compiler-credentials"/> <!--Subject metadata--> <wsbs:SubjectMetadata URI="#source:MyPersonalPlanner:AddAppointment"> <wsbs:targetLanguage> <wsbs:Name>bytecode</wsbs:Name> <wsbs:Version>45...com:sw:05a3"/> </wsbs:ActorIdentity> <!--Actor credentials--> <wsbs:CredentialsReference URI="..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..org/2000/09/xmldsig#"> ./saml-verifier-credentials"/> 53 .com:sw:05a2"/> </wsbs:ActorIdentity> <!--Actor credentials--> <wsbs:CredentialsReference URI="..

.DeleteAppointment.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:VerificationType>ProofDelegation</wsbs:VerificationType> <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:VerificationType>ProofDelegation</wsbs:VerificationType> <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="./saml-author-credentials"/> <!--Subject metadata--> <wsbs:SubjectMetadata URI="#source:MyPersonalPlanner:DeleteAppointment"> <wsbs:ProgrammingLanguage> <wsbs:Name>Java</wsbs:Name> <wsbs:Version>1.....w3.....xsd"/> 54 .5</wsbs:Version> </wsbs:ProgrammingLanguage> <wsbs:Description> Removes an appoinment from the personal planner </wsbs:Description> <wsbs:InterfaceSchema URI=".</ds:Reference> . <ds:Reference URI="#psc-cert:MyPersonalPlanner:AddAppointment:VerifiedCode"> .org/2000/09/xmldsig#"> ../MyPersonalPlannerPolicy#AddAppointment:VerifiedCode" > </wsp:PolicyReference> </wsbs:SubjectPolicy> <ds:Signature xmlns:ds="http://www./MyPersonalPlanner.. </ds:Signature> </wsbs:VerifiedCode> </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="..

<ds:Reference URI="#psc-cert:MyPersonalPlanner:DeleteAppointment:AuthoredCod"> .</wsbs:License> <wsbs:Result> <wsbs:ActionTime>2007-05-02T09:45:00Z</wsbs:ActionTime> <wsbs:VersionHistory> <wsbs:VersionDescription wsbs:VersionNumber="1.org/2000/09/xmldsig#"> .w3./MyPersonalPlannerPolicy#DeleteAppointment:AuthoredCode" > </wsp:PolicyReference> </wsbs:SubjectPolicy> <ds:Signature xmlns:ds="http://www../MyPersonalPlannerPolicy#DeleteAppointment:SuppliedCode" > </wsp:PolicyReference> </wsbs:SubjectPolicy> <ds:Signature xmlns:ds="http://www....</ds:Reference> ......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.0"> Initial </wsbs:VersionDescription> <wsbs:VersionDescription wsbs:VersionNumber="1.w3...1</wsbs:Version> <wsbs:License wsbs:licenseType="GPL">.. </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=".1"> Check if exists previously </wsbs:VersionDescription> </wsbs:VersionHistory> </wsbs:Result> </wsbs:SubjectMetadata> <wsbs:SubjectPolicy> <wsp:PolicyReference URI="...org/2000/09/xmldsig#"> 55 .

3</wsbs:Version> </wsbs:targetLanguage> <wsbs:compilerEnvironment wsbs:VersionNumber="5. <ds:Reference URI="#psc-cert:MyPersonalPlanner:DeleteAppointment:CompiledCode"> ..org/2000/09/xmldsig#"> .w3....</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. </ds:Signature> </wsbs:CompiledCode> <!--metadata added by verifier--> <wsbs:VerifiedCode wsu:Id="psc-cert:MyPersonalPlanner:DeleteAppointment:VerifiedCode"> <!--Actor identity metadata--> <wsbs:IndentityReference URI="#MyPersonalPlanner:Verifier"/> <!--Actor credentials--> <wsbs:CredentialsReference URI="....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="..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> ../MyPersonalPlannerPolicy#DeleteAppointment:CompiledCode" > </wsp:PolicyReference> </wsbs:SubjectPolicy> <ds:Signature xmlns:ds="http://www..... <ds:Reference URI="#psc-cert:MyPersonalPlanner:DeleteAppointment:SuppliedCode"> ../saml-verifier-credentials"/> 56 ....

...0</wsbs:Version> <wsbs:Structure URI=". <ds:Reference URI="#psc-cert:MyPersonalPlanner:DeleteAppointment:VerifiedCode"> .xsd"/> </wsbs:DataFormat> <wsbs:Description> List of appoinments from the Personal Planner </wsbs:Description> 57 ..org/2000/09/xmldsig#"> .....</ds:Reference> .w3.. </ds:Signature> </wsbs:VerifiedCode> </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=".state../MyPersonalPlannerPolicy#DeleteAppointment:VerifiedCode" > </wsp:PolicyReference> </wsbs:SubjectPolicy> <ds:Signature xmlns:ds="http://www...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:VerificationType>ProofDelegation</wsbs:VerificationType> <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:VerificationType>ProofDelegation</wsbs:VerificationType> <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="./MyPersonalPlanner./saml-owner-credentials"/> <!--Subject metadata--> <wsbs:SubjectMetadata URI="#xmllist:MyPersonalPlanner:CurrentState"> <wsbs:DataFormat> <wsbs:Name>XML</wsbs:Name> <wsbs:Version>1.

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 .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.. <ds:Reference URI="#pss-cert:MyPersonalPlanner:CurrentState:OwnedData"> ....ietf.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.</ds:Reference> .0"> Initial </wsbs:VersionDescription> </wsbs:VersionHistory> </wsbs:Result> </wsbs:SubjectMetadata> <wsbs:SubjectPolicy> <wsp:PolicyReference URI="../saml-converter-credentials"/> <!--Subject metadata--> <wsbs:SubjectMetadata URI="#xmllist:MyPersonalPlanner:CurrentState"> <wsbs:targetFormat> <wsbs:Name>csv</wsbs:Name> <wsbs:Version>1....org/2000/09/xmldsig#"> ...0</wsbs:Version> <wsbs:Structure URI="http://tools. </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="./MyPersonalPlannerPolicy#CurrentState:OwnedData" > </wsp:PolicyReference> </wsbs:SubjectPolicy> <ds:Signature xmlns:ds="http://www.w3..org/html/rfc4180"/> </wsbs:targetFormat> <wsbs:ConverterEnvironment wsbs:VersionNumber="5.

.... </ds:Signature> </wsbs:ConvertedData> <!--metadata added by state verifier--> <wsbs:VerifiedData wsu:Id="pss-cert:MyPersonalPlanner:CurrentState:VerifiedData"> <!--Actor identity metadata--> <wsbs:IndentityReference URI="#MyPersonalPlanner:Verifier"/> <!--Actor credentials--> <wsbs:CredentialsReference URI="....</ds:Reference> ../MyPersonalPlannerPolicy#CurrentState:VerifiedData" > </wsp:PolicyReference> </wsbs:SubjectPolicy> <ds:Signature xmlns:ds="http://www.. </ds:Signature> </wsbs:VerifiedData> 59 ....</ds:Reference> ..../saml-verifier-credentials"/> <!--Subject metadata--> <wsbs:SubjectMetadata URI="#xmllist:MyPersonalPlanner:CurrentState"> <wsbs:VerificationType>Integrity</wsbs:VerificationType> <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:VerificationType>Integrity</wsbs:VerificationType> <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="..org/2000/09/xmldsig#"> ./MyPersonalPlannerPolicy#CurrentState:ConvertedData" > </wsp:PolicyReference> </wsbs:SubjectPolicy> <ds:Signature xmlns:ds="http://www.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=".org/2000/09/xmldsig#"> .w3.w3. <ds:Reference URI="#pss-cert:MyPersonalPlanner:CurrentState:ConvertedData"> .. <ds:Reference URI="#pss-cert:MyPersonalPlanner:CurrentState:VerifiedData"> ..

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:VerifiedMethodData wsu:Id="psms-cert:MyPersonalPlanner:VerifiedMethodData"> <!--Actor identity metadata--> <wsbs:IndentityReference URI="#MyPersonalPlanner:Verifier"/> <!--Actor credentials--> <wsbs:CredentialsReference URI="../saml-verifier-credentials"/> <!--Subject metadata--> <wsbs:SubjectMetadata URI="#o:MyPersonalPlanner"> <wsbs:VerificationType>StateAppraisal</wsbs:VerificationType> <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="....org/2000/09/xmldsig#"> ..../MyPersonalPlannerPolicy#VerifiedMethodData" > </wsp:PolicyReference> </wsbs:SubjectPolicy> <ds:Signature xmlns:ds="http://www.</ds:Reference> . </ds:Signature> </wsbs:VerifiedMethodData> </wsbs:psms-cert> </wsbs:pso-cert> </wsbs:pso> 60 .. <ds:Reference URI="#psms-cert:MyPersonalPlanner:VerifiedMethodData"> .w3...

w3..org/2000/09/xmldsig#" xmlns:xs="http://www..."> <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:VerificationType"/> <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 .org/ns/ws-policy" xmlns:uddi="urn:uddi-org:api_v3" targetNamespace=".w3.0" encoding="UTF-8"?> <xs:schema xmlns:wsbs=".xsd" xmlns:ds="http://www.w3..A continuación se muestra el XML-schema correspondiente a un PSO." xmlns:wsu="http://docs.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1. XML-Schema of PSO 1 2 3 4 5 6 <?xml version="1.oasis-open.org/2001/XMLSchema" xmlns:wsp="http://www.0.

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="VerifiedCode" 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="qualified"/> </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="qualified"/> </xs:extension> </xs:simpleContent> </xs:complexType> </xs:element> </xs:schema> 63 .

sustanciados en dos comunicaciones en sendos congresos. uno de ámbito internacional y otro nacional. 550 . Rodríguez Priego. 2007. A continuación se incluyen los textos de ambas publicaciones. García. Italia. "Securing objects in Services Oriented Architecture".555. Rodríguez Priego. Springer Verlag. Rodríguez Priego. pp. F. que tendrá lugar del 12 al 13 de Septiembre del presente año en Zaragoza.J. que tendrá lugar del 16 al 20 de Julio del presente año en Como. . Comunicación: E. 2. incluida en el Journal Citation Reports (JCR). 3. F. que será presentada en la III Jornadas Científico Técnicas en Servicios Web y SOA (JSWeb 2007). Comunicación: E. Publicación: E. F.Apéndice C Publicaciones y Trabajos presentados en Congresos El trabajo de investigación ha producido resultados significativos. A continuación se recogen las referencias a los congresos y las publicaciones asociadas: 1. García. LNCS 4607. "Securing Code in Services Oriented Architecture".J.J. "Securing Code in Services Oriented Architecture". Es reseñable que la comunicación presentada en el Congreso internacional será publicada en la serie Lectures Notes in Computer Science. que será presentada en la International Conference on Web Engineering 2007 (ICWE07). García.

Baresi. 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. Luis de Ulloa s/n E-26004 Logrono (La Rioja. it’s 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. visibility. 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.-J. Fraternali.J. 2]. a consuming entity requests from a supplier entity. This new model allows the development of systems with end-to-end security. 550 – 555. policies and contracts). The proposed security mechanisms of the SOA model and the technology of web services are centered in the transmitted data (message). Spain) {emilio. and they put their focus on end to end integrity. the performed action details of the supplied service are not typically visible by the consumer [1. francisco. delegating the effective resolution of these problems to the supplier. confidentiality. SOA proposed security mechanisms are only centered in the data transmitted between service provider and consumer. identity and authentication. Recently different standard-based solutions have been proposed to solve the problem of secure sending and reception of messages. mobile code security. Therefore SOA does not address the subjects related to the realization of a service.g. one or more services under a set of conditions (interaction. In this paper we present a new approach about mobile code security based on the Services Oriented Architecture Reference Model and Web Services technology. Keywords: Web services security. L. Service Oriented Architecture. These mechanisms work well and in practice they reach the objective. 2007.garcia}@unirioja. e. 1 Introduction to the Problem Nowadays.Securing Code in Services Oriented Architecture Emilio Rodriguez Priego and F. P. Houben (Eds.): ICWE 2007. and G. According to SOA. like. execution context. © Springer-Verlag Berlin Heidelberg 2007 . there is a growing interest in Web Services technology and Service Oriented Architecture (SOA). LNCS 4607. it’s 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.rodriguez. García Departamento de Matemáticas y Computación Universidad de La Rioja Edificio Vives. whose Reference Model has been recently approved as an OASIS standard [2]. In this model. However. securing it.es Abstract.9]. At the same time. However. where all elements (code and data) are secure. in which there potentially exists diverse security threats. pp.

auditing and validation of code by certification entities. 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.e. named “Web Services based Secure Code” (here-in-after WSbSC) that it’s based on SOA Reference Model and the Web Services Architecture.7]. Most proposals are based on hardware or software techniques for execution in a local environment. resolution outline and methodology.Securing Code in Services Oriented Architecture 551 Therefore. In Section 2. The main contribution of this article is the proposal of a new approach to the problem of the security of mobile code. the status of the research and indicates the future work. integrity and confidentiality). take part or are exchanged as part of services provided by the supplier. in certain situations code visibility. (2) the code can be executed in any compatible execution environment. 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. and (4) the code can be verified in a secure manner. involving data and code was required. Our model is virtually applicable to any SOA situation in which an integral model of security. validation and execution in distributed environments [4. the security problem of mobile code and its interaction with the environment in which code is executed has been studied in the last years. the source of the code or all of these elements. The central concept in WSbSC-RM is the code. Both SOA and mobile code have specific and common aspects of security but until now had not been treated jointly. Once the problem that we want to address has been stated. Section 3 presents the application of the model to a basic SOA interaction. Independently of the web services development and SOA model. enabling the development of specific architectures using consistent standards or specifications. the rest of the paper is organized in two main sections. There have been different proposals related to code portability. . integrity and/or portability are more important. The last section summarizes the main contribution. we provide a general description of the WSbSC reference model. each one describing its own objectives. and so on. just as it has been defined traditionally but with some specific features: (1) the code can be portable: i. WSbSC-RM relies on SOA-RM and it adds new concepts and relationships to the modeling of data and code exchange based on services. 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. Typical examples of these application environments are distributed processes. the code in itself.5. (3) transmission. because code integrity. it can be sent from one system to another without manual intervention. particularly for the singular case of mobile agents [6]. related work.. hosting or rent of processes. 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. However.

Client: uses the code provided by a supplier. Supplier: provides the code to a consumer and distributes it by author permission. with WSbSC code is not only externally verifiable [3]. Compiler: given a code. This policy refers to one or several security aspects (such as integrity. policy. confidentiality. depending on the mechanisms the former can implement. does not only affect the data (message) as SOA does. García WSbSC-RM states that the transmission. Priego and F. reception. 1 shows this general scenario. from the point of view of SOA-RM. Processor: possesses an execution environment that executes the code.J. Fig. compilation and validity of the code are services that can be offered by systems potentially remote and weakly coupled. (2) A client localizes and requests the code that satisfies its needs from the supplier. 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. but we can illustrate these relationships by describing a general example that shows some key concepts in SOA-RM: service. load. Interactions involve the following steps: (1) An author creates the code and sends it to a supplier for distribution. What is a key added factor of our approach with reference to SOA. as well as the result. (3) The supplier delivers the code. and so on) and may specify a mechanism or set of mechanisms that the provider must implement to accomplish the policy. Verifier: verifies the code according to a security policy previously established. interaction. 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. it compiles another functional equivalent code. validity. metadata about the required. 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. As we see below. 1. The response to each service request will include. and fulfilled. All WSbSC-RM actors are service consumers or providers. (6) If code is not compiled for the architecture in which is going to be . (5) The verifier delivers the validated code. real world effect. General WSbSC-RM scenario At this point.552 E. but also the service implementation. policies and contracts. 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. etc. we have not studied yet all relationships between WSbSC-RM actors like service actors. (4) The client requests the verification of the code according to the client policy from a verifier. execution. This policy.R. and here is the contribution. These security requirements can be used by the consumer to select the most suitable provider in each case.

provided (supplier). This means that at the end of the process we can get a code qualified as "secure" since it's created (author). This PSC-cert allows a client to test that the code is PSC while the code itself is not revealed. 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. validated (verifier) and generated (compiler) by trusted identified entities. 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. (9) The verifier returns the validated code. We consider a consumer entity that uses a service offered by a provider entity. e. There can be diverse variations of this general scenario. We have that PSC = Code + PSC-cert (cert stands from certificate). Fig. At point (9) the code is associated to the verifier's signature that guarantees its integrity. 2. (10) The client requests to a processor execution of the code. the overall process can be checked if each actor signs its action. (7) The compiler returns the compiled code. or even correctness with respect to a certain specification. 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. As you can see in Fig. [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.Securing Code in Services Oriented Architecture 553 executed then the client requests its generation from a compiler. after the step (2). before execution by means of that signature. The Processor can verify code integrity. 2.g.. Service Implementation with WSbSC . 2 shows how a provider entity relies on WSbSC to get a higher security level. For example. Moreover. (11) The processor returns the result of the process to the client. each step generates metadata signed by the service provider. the PSC-cert accompanies the service result returned to the service consumer. This code. As a result. as well as its signature. that we'll name Portable Secure Code (PSC) is formally "portable" and "secure". the result code of the compiler can include metadata related to that compilation. (8) The client can request validity of the compiled code from the verifier.

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

Communications of the ACM (August 2003) 9. and in order to select the standards to be used at each part of the PSC-cert (SAML. Acknowledgments. Reig. and so on)... M. V. B. References 1. com 10. A. van Doorn. P. Sekar. A. virtual machines and emulators (June 2003) 5. WS-Policy. Status and Future Work Several solutions about mobile code has been proposed in the last years: e.: How can mobile agents do secure electronic transactions on untrusted hosts? A survey of the security issues and the current solutions.. Preneel. C.0 October 2006 http://docs. [7] and more recently [10] suggest a contract between producer and consumer of mobile code.s3ms.fast...pdf 3. J. SENSORIA (October 2004) http://sensoria. L.: A portable Virtual Machine target for Proof-Carrying Code.E. UDDI. Luk. In: Fourth International Workshop on Object-Oriented Real-Time Dependable Systems (WORDS’99) (1999) 6. making this code PSC. securitydocs.org/TR/ws-arch/ 2.. Franz.. Reference Model for Service Oriented Architecture v1. Sima. X. ACM Transactions on Internet Technology (TOIT) (February 2003) 7. [4. Vandewalle.V. C. Related Work.g. Gal.R. Wang.. Security of Software and Services for Mobile Systems (March 2006) http://www.: An Object-Oriented Approach to Containing Mobile and Active Codes in Large-Scale Networks. M.0/soa-rm.Securing Code in Services Oriented Architecture 555 4 Contribution. Whitman. D. S. Communications of the ACM (September 2006) 4.S. Seshadri. In: Proceedings of the 2003 workshop on Interpreters.5. verifier and/or processor).e. Smolka.. J..: Model-Carrying Code (MCC): a new paradigm for mobile-code security... WSbSC provides a level of security that covers not only the data but also the code that process these data. WS-Addressing.w3. securing the object state as well as the code that manages that state (behavior). The main contribution of this paper is the proposal of a new approach to the problem of the security of mobile code.: Enemy At The Gate: Threats To Information Security. both to specify the demanded policy and the process that must be preformed to implement it (perhaps using WS-SecurityPolicy or even BPEL). Partially supported by Comunidad Autónoma de La Rioja.: Externally verifiable code execution. I. M. N.oasisopen..A. Haldar. In: Proceedings of the 2001 workshop on New security paradigms (September 2001) 8. A. Yau.org 11. A.. R. project ANGI-2005/19.org/soa-rm/v1. As a future line of research we are planning to extend the model to portable objects. that it’s based on SOA-RM and the Web Services Architecture. i. A lot of work must be done.... WSbSC. Perrig. S. [11] defines a model-driven approach for service-oriented software development. Claessens.: Are your web applications vulnerable? (October 2004) http://www. Khosla. Web Services Architecture (February 2004) http://www.6] focus on execution environment (compiler. Zhou. F. Ramakrishnan. Ramakrishnan. Chandra. Prasad.de/ . words..

In this context. intranet) and public (e. Nowadays. identity and authentication. they can address old problems related to interaction between potentially remote systems.rodriguez. We analyze general problems related to the exchange of code and state in SOA and in the specific case of Web Services architectures.garcia}@unirioja. Web Services Architecture (WSA) [18].es Abstract. and. Basic concepts treated by SOA-RM are: service.g. francisco. whose Reference Model has been recently approved as an OASIS standard [14] is notorious. SOA can be applied both in local (e. They put their focus on end to end integrity. Service Oriented Architecture (SOA) and Web Services are claiming a lot of interest because. So. but they forget the code security. a change to the shared state of defined entities or some combination of both. Introduction The current interest in Web Services technology and Service Oriented Architecture (SOA). 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. This model covers any aspect related to the authorship. we extend a previous approach about securing code in SOA. SOA and WSA Architecture share common concept. code plus state (objects). A new general model of security is presented. WSA can be seen as a specific application of SOA model. Keywords: Web services security. In certain situations (parallel computing. Moreover. 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”. a lot of web services standards are evolving. execution and validation of both code and data. policies. Currently. security solutions focus on messages and data. and so on. That model represents a conceptual framework for interactions between consumers and providers of services.. distribution. visibility. SOA-RM focuses on the service as a central concept of interaction between a generic consumer and a provider.J.Securing objects in Services Oriented Architecture Emilio Rodriguez Priego and F. On the other hand. it may be convenient the exchange of code. whilst it is well known . in a more general case. approved as W3C Working Group Note. Service Oriented Architecture 1. execution context. code security is not generally addressed. particularly related to security policies. Policies and contracts are other SOA central concepts.. Internet) environments and it’s in the last case where the security importance is more releveant. These mechanisms work well and.). contracts. confidentiality.. mobile code security. In this paper. interaction. most of them about security issues. most works related to SOA are developed under Web Services Architectures. being security one of the critical aspects. Luis de Ulloa s/n E-26004 Logroño {emilio. provides a conceptual model and a context for understanding web services. although code and/or state not being exchanged.. above all. etc. García Departamento de Matemáticas y Computación Universidad de La Rioja Edificio Vives. they are applied to messages. we propose that any security approach will be incomplete if both data and code security are not addressed. using robust technologies like Internet and XML. However.g. hosting of processes. transformation. Most SOA based solutions are based in web services technologies and security mechanisms.

The remainder of the article is organized as follows. In that work. This paper is the continuation of a previously presented work [7]. confidentiality. executed in any compatible execution environment. but also objects as input and/or output “data”. just as it has been defined traditionally but with some specific features: it can be portable. Section 2 is devoted to show some background necessary to understand the rest of the paper. 2. This model enables the development of specific architectures using consistent standards or specifications. • Verifier: verifies the code according to a security policy previously established. we presented an approach about code security on SOA environments that can be applied on web services architectures. WSbSC-RM relies on SOA-RM but it adds new concepts and relationships to the modeling of data and code exchange based on services. In that paper we presented three central concepts: WSbSC-RM. • Compiler: given a code. We named that approach “Web Services based Secure Code” (here-in-after WSbSC) and its reference model WSbSC-RM.1. All WSbSC-RM actors are service consumers or providers. and here is the contribution. 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 refers to one or several security aspects (such as integrity. from the point of view of SOA-RM. WSbSC-RM states that the transmission. but also externally compilable and externally executable. PSC and PSC-cert. This paper aims to extend WSbSC reference model in a more complex situation in which entities wish to exchange not only data. 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]. Section 4 deals with performance issues and paper finalizes with related work. WSbSC-RM distinguishes these actors: • Author: it's the owner and creator of the code and its legal owner. contribution and future work. validity. it compiles another functional equivalent code. WSbSC. • Supplier: provides the code to a consumer and distributes it with the author permission.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]. but also the service implementation. Section 3 describes how can to be extended WSbSC from a object-oriented perspective. And this policy. The central concept in WSbSC-RM is the code. • Client: uses the code provided by a supplier. load and execution of the code can be carried out in a safe way. load. does not only affect the data and the message as SOA does. • Processor: possesses an execution environment that executes the code. As we see below. 2. compilation and validity of the code are services that can be offered by systems potentially remote and weakly coupled. and more specifically on web services architecture. 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 . transmission. and it can be verified in a secure manner. with WSbSC code is not only externally verifiable [2]. 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. execution. 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. reception.

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

b) corresponds to an scenario like the one described in section 2..b. …). imagine that the scenario corresponds to the interaction between a flight reservation service and final users. The following blocks are added in the same way by each actor when they have finished their tasks.c are more complex than for case 3. common security mechanisms such as public-key cryptography can be used to securing only the exchanged data (WSSecurity. like elements exchanged. e. once the flight has been selected. and. Note that sections marked with (*) consist of two main parts: metadata related to the actor (description. SAML. the service inserts a new appointment in the planner. and so on. and for the particular case of Web Services. The next step in the discussion is the study of a scenario where the code travels between consumers and service providers. During its execution. Security requirements in case 3. XML-DSIG. Figure 3 shows the general picture of the three basic scenarios where a consumer entity requests a service from a provider entity.) and metadata about its action. assuming that an object is data plus code. and so on. allowing the service to use its methods. E. for example [6]. the service requires an object from the consumer as input. they agree to use WSbSC to get a higher level of security about the performed Figure 3 WSbSC-RM Information Model Cases . Code may travel and not be locally executed for performance reasons.added together with author’s signature of that block. e.b) but its interactions (use and/or modification) with the input object are secure.g. WS-Policy.. the service will interact with this object and eventually it will modify the object state. In it. In it.g. Therefore.. This is the common information model found in SOA. In the first case (3. The second case (3. we have proposed a model in which the secured code is located in the service provider. We also show how to apply an analogous approach in order to secure the object state and the whole object (state + methods).a). by means of UDDI business entity. e. for the compiler: the compiler environment. Case 3.g. 3. The service needs to consult the planner calendar to determine the user availability. The object. who send their personal planner object. the target language. 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. SAML authorization credentials. the consumer and the provider entities exchange only data. credentials.g. helps the service to fully accomplish its mission. in turn.c depicts this new scenario.. So far. because the consumer and the provider want to ensure that not only the service (as in case 3.

e.1. • Verifier: optionally. we can distinguish actors related to object’s state (data). Interaction begins when Consumer Entity A requests a service from provider entity B. First of all A has to get a certificate of both methods. • Supplier: optionally. Figure 4 shows how we can achieve these high level security requirements for this scenario using WSbSC approach. this is similar to case (3.a) where data can be secured by A and B using well-known security mechanisms. Securing object’s state. In Figure 4 Portable and secure objects with WSbSC . WSbSS-RM A and B could need the same level of security for state than for code. Note that state can represent relevant data that an entity owns. However. being M1 and M2 the object methods and S its state. it verifies the data for consistency. we can get a higher level of security for the state. • Converter: optionally. Code Author Supplier Compiler Verifier Data Owner Supplier Converter Verifier Table 1. 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).. In the same way as was done for the code in section 2. If it hasn’t done so previously. The security policy of the consumer requires that the provider access and/or modifies the object state only by means of the object methods. 3. We can address this problem using WSbSC. Let’s suppose that the service requires a single object O1 as input. the state can have a structure and the verifier tests this structure and the integrity of the state. the owner can be delegate in this actor the action of providing the state to another entity. Code/data actors duality Table 1 shows code/data actors duality. We can consider that these actors virtually offer services about state: • Owner: the owner of the state.service. Both A and B establishes security policies about code using WSbSC-RM. The initial problem is that B does not allow untrusted code to execute. Apparently. This proves to B that code received from A is secure. 4. similarly to code. But this is not enough yet.g. it follows steps described in section 2 and gets PSC-cert(M1) and PSC-cert(M2). A in Fig.

e. A receives the results of the service including O1. the state of the object has been identified (owner) and. private and fundamentally unknowable”. we can call the dual reference model for the state WSbSS-RM (Web Services based Secure State – Reference Model). We call the certificate that aggregates both state and methods metadata PSOcert.2. when the service has finished. they have shared “facts” and processes from a “real world” point of view. We assume that A and B trust actors described above. or more precisely the recompiled versions of M1 and M2. Note that for performance reasons. A can check integrity of M1. 3. compile to generate code compatible with its execution environment). A and B may even share some of those actors. Using the analogy of WSbSC-RM for code. without needing to know the method details. Consumer and Provider policies have to state in which circumstances a PSO-cert update is required. Continuing the analogy with code.a. A sends B O1 with PSO-cert(O1). This certificate will be generated by the data actors. Securing objects’ state and methods At this point. A also receives: • The PSO-cert (O1). 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. so B has to transform it (e. Global process is distributed. Consequently. M1 and M2 has been compiled. if examining original M1 and M2 PSC-certs.general. When B returns the service result to A.g. verified and executed by trusted actors. Securing legal access to state through object methods . and that the objects state may have been converted and verified by trusted parties also. provided (supplier). going back to Fig. these actors can be local o remote. eventually. the service consumer gets basic metadata related to the object state. and B only handles O1 through its methods.. 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). Moreover. Therefore. Now. Perhaps the M1 and M2 code is not suitable for its execution in B’s processor. S’ and the service implementation as was described previously. PSO-cert(O1) = PSCcert(M1) + PSC-cert (M2) + PSS-cert (S). In fact. for the moment. B performs the service using M1 and M2 to access and/or modify O1 state. it will have to certify that M1 and M2. we can consider that A doesn’t know either B’s internal actions to realize the service neither its initial nor final state. M2 (executed in B). that certifies that object methods are securely executed. In our example. B realizes that its compiler environment is compatible with M1 and M2. i. in an untrusted execution environment. A should not allow the execution of O1 methods. and consequently its state access/modification. by definition. that certifies that the service code also is secure as WSbSC mandates So. Now O1 may have a new state S’ due to the interaction with B. Note that it isn’t necessary to generate metadata from all WSbSC-RM actors. We want to borrow some ideas from SOA and stress the fact that they are also observed in WSbSC and WSbSS. the security level that the PSO-cert(O1) that B has . WSbSC-RM adds the focus on “shared process” too.. we will call this metadata PSS-cert (Portable and Secure State). 4 schema. were securely executed in B as WSbSC mandates. 3. WSbSS-RM allows providing a further level of security on data with respect to scenarios such as the depicted in Fig 3. B has received the code of M1 and M2. Although A and B don’t know neither the process nor the state details. There is a trade-off between security and performance. SOA-RM focuses on “the sets of facts shared by the parties”. • And the PSC-cert for the implementation of the service.3. both consumer and provider haven’t to get PSO-certs every time. B does not need to compile them again and it can use compiled code offered by A. This fact is returned to A in the form of M1 and M2 PSC-certs.WSbSO-RM It must be observed that. and eventually recompiled in a trusted environment. Surely. verified. generated (compiler) and validated (verifier) by trusted actors that sign their actions with a certificate. For example. it has been converted (converter) and validated (verifier) by trusted actors also.

PSO-cert includes complete information about security of code. Following the notation used with WSbSC and WSbSS. and so on. virtual machines [13] and verifiers [4.. it must be guaranteed that the object state can only be managed by means of its methods. code verifiers. • It isn’t necessary PS*-certs to be obtained in every interaction. Another approach may be that the verifier reproduces the state modification following the same sequence of operations that B has performed. In order to define PS*-certs. The central point in this approach is that both service consumer and provider have to define their respective security policies related to WSbS*-RM. verifier actor role can be played by only one hardware component [17] and in this case. PSC and PSS can be transmitted in a secure manner using WS- A considerable amount of work. PS* and PS*-cert could be introduce a significant overhead and a poor performance. Due to space limitations a more detailed discussion about that approach is avoided.. • We state that WSbS* actors are always present in some way and in any scenario. Providers and consumers policies can establish when they must be obtained. by means of session mechanism. While central problems about data and code verification have been addressed from different points of view. Finally UDDI. some of it rather old.. being the mobile agents scope the research field where the problem has been mainly addressed [10]. state and its relationship. XML-Encryption. as a future line of research. but they do not necessarily adopt the form of web services. e. [3. Performance issues In previous sections. On the other hand. e. e. WSbS*-RM can be applied independently. In general.g.16] and more recently in [8]. 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. a new verifier actor is needed. The main contribution of our paper is the definition of a conceptual framework where all these approaches can be modeled. We must consider some issues about performance: • Roles of different actors can be played by a same entity.1] studied security aspects about Mobile code and Mobile agents and diverse solutions for specific security threats were proposed. the problem of securing legal access to the state through the object methods is a more complex task. a conceptual framework has been described based on concepts from SOA and WSA. XML-Dsig. B’s processor must provide the verifier with this sequence of actions. Security standard. SAML and XMLSchema enable security and mechanisms to ensure all security issues described. However. We can outline how we can address the implementation of this model for each specific scenario using Web services standards. The described models define a general and perhaps the most complex scenario where all actors are different entities. Future Work Contribution and 4. In this case. wherever the object is used. e.g. state verifiers and object verifiers of both service consumer and provider can be the same trusted Certificate Authority. E.g. allowing diverse levels of security. Therefore. Security contracts and policies were analyzed in [5.g. To reach such a guaranty. we name Web Services based Portable and Secure Object Reference Model WSbPSO-RM.. This simplifies construction of PSC-certs and improves the performance. Also.. Implementing the model with web services.10. Related work.11]) have been presented from different points of view. has been done on several aspects treated here. 5. like it was a log file. we are planning to address this problem from a WSbSORM perspective using secret sharing techniques. Besides. is the most suitable standard to get a reference for the identity of each WSbS* actors.built offers is not enough. each one of the execution environment actors (compilers and processors. only at the beginning of the first interaction. 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. PSO.g. a CRC or another mechanism can be used in the PSC-certs. we propose an extra level of security in a service . Expression of these policies can be based on WSPolicy.

3. August 2003 [13] Michael Franz. Andrew D. ModelCarrying Code (MCC): a new paradigm for mobile-code security. 342-361. Philip W-L Fong. "Understanding Code Mobility. Mark Luk. Nov/Dec. A.w3. C. Gordon. Proceedings of the 2003 workshop on Interpreters. pp. Geer. September 2001 [17] Trusted Computing Group (TCG).org. Proceedings of the 2005 ACM SIGPLAN international workshop on Types in languages design and implementation.0/soa-rm. “The open verifier framework for foundational verifiers”. George C. May. Fermín Reig." IEEE Internet Computing. I. Finally. García. March 1999 [7] Emilio Rodríguez Priego. Proceedings of the 2001 workshop on New security paradigms. virtual machines and emulators. 30-34. 6. “Enemy At The Gate: Threats To Information Security”. Cédric Fournet. Andreas Gal.. Devanbu.org/TR/ws-arch/ . Communications of the ACM.J. “Implementing Trusted Computing”. Gutiérrez. “Externally verifiable code execution”. “Web Services Enterprise Security Architecture: A Case Study”. June 2003 [14] OASIS.fast. 24. January 2005 [5] C.s3ms. 5. ACM Transactions on Internet Technology (TOIT) [11] Karthikeyan Bhargavan. Ning Wang. Necula. Stuart G. Piattini. Our main lines of research are: (1) to work on the implementation of the model in several real world scenarios.de. Proceedings of the 11th ACM conference on Computer and communications security. Stubblebine. an incremental model of security based on certificates issued by each model actor provides a means for ensure security and achieve a trusted environment. February 2003. v. pp. Pradeep Khosla. Ramakrishnan. March 2006 [9] European Project. Schneck . S. "Mobile Code Security. november 11. Fernández Medina and M.3). “(How) can mobile agents do secure electronic transactions on untrusted hosts? A survey of the security issues and the current solutions”.42 n." IEEE Transactions on Software Engineering. Deepak Chandra. “Verifying policy-based security for web services”. Sekar. Mitsuru Oshima. Bart Preneel. E. 2005 [6] Danny B. (2) to improve security between state and methods using secret sharing tecniques (as commented in section 3. no. “TPM Overview”. Leendert van Doorn. Rubin. Communications of the ACM. vol. . Web Services Architecture http://www. “Securing Code in Services Oriented Architecture”. Whitman. “SENSORIA”. V. Gian Pietro Picco. http://sensoria. no.8889. Adam Chlipala. [8] European Project. Giovanni Vigna. 02. Lange . October 2004 [10] Joris Claessens.pdf [15] Premkumar T. Adrian Perrig.0 http://docs. R. 1998 [2] Arvind Seshadri.interaction considering both code and state. Vivek Haldar. Proceedings of the 20th international conference on Software engineering. “Seven good reasons for mobile agents”. september 2006. “A portable Virtual Machine target for ProofCarrying Code”. 1998 [4] Bor-Yuh Evan Chang. Jr. Referencias [1] Alfonso Fuggetta. “Security of Software and Services for Mobile Systems”. F. Smolka . http://www.2” [18] W3C. October 2004 [12] Michael E. Ramakrishnan. [3] Aviel D. Joos Vandewalle. SWS'05. Reference Model for Service Oriented Architecture v1.org/soa-rm/v1. p. ICWE07 (to be published). Robert R. “TCG Specification Architecture Overview v1. Communications of the ACM. “Techniques for trusted software engineering”. Daniel E. April 1998 [16] R. vol.oasis-open.

.Apéndice D Presentaciones En este Apéndice se incluye una copia de la presentación cuya exposición se realizará en el Congreso ICWE07 que tendrá lugar del 16 al 20 de Julio de 2007 en Como (Italia).

Italy . 2007 Como. García Izquierdo International Conference on Web Engineering July 16-20.Securing code in Service Oriented Architecture Emilio Rodríguez Priego F.J.

Our solution 3.... status and future work .Conclusions.3 Service implementation with WSbSC 4..2 WSbSC reference model 3.Index 1..Problem description 3.Introduction 2.Related work 5.1 Starting point: SOA and WSA 3.

Description of the problem 3. 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.1 Starting point: SOA and WSA 3. status..3 Service Implementation 4.Our Solution 3. mainly by W3C and OASIS Application of standards is not enough .-Related work 5.Introduction 1-Introduction 2.-Conclusions..2 WSbSC-RM 3.

Problem Description 3.. channel. i. code problems. future work Security efforts are mainly focused on trust entities..2 WSbSC-RM 3.3 Service Implementation 4.Our Solution 3. Security problems about code are not usually addressed. 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? . viruses … For a long time.2. bugs. status.Problem Description 1-Introduction 2. message and data.e .-Related work 5.1 Starting point: SOA and WSA 3.-Conclusions.

2 WSbSC-RM 3.3 Service Implementation 4. future work We need a model for security of code in service oriented architecture but … first.3. status.Problem Description 3.. we need to improve SOA/WSA to consider code Our starting point SOA-RM Model WSA Model ..Our Solution 3.-Related work 5.Our solution 1-Introduction 2.-Conclusions.1 Starting point: SOA and WSA 3.

2 WSbSC-RM 3. status.SOA-RM: concepts & relationships SOA-RM main concepts Service Visibility Interaction Real world effect Service description Execution context Contract & Policy 1-Introduction 2.-Related work 5.-Conclusions..Our Solution 3. future work .3 Service Implementation 4.Problem Description 3.1 Starting point: SOA and WSA 3..

.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.-Related work 5. status.Problem Description 3.-Conclusions. future work .Our Solution 3..3 Service Implementation 4.2 WSbSC-RM 3.1 Starting point: SOA and WSA 3.

1 Starting point: SOA and WSA 3. future work .Our Solution 3.Problem Description 3..2 WSbSC-RM 3.3 Service Implementation 4.-Related work 5. status.-Conclusions.Web Services Architecture WSA It’s conformant to SOA Use XMLbased standards The channel is generally Internet 1-Introduction 2..

-Conclusions. status.Our Solution 3. Verification is known by the parties Applicable to general scenarios and in particular: Distributed processes Hosting or renting of processes ..2 WSbSCWSbSC-RM 3.-Related work 5.3 Service Implementation 4.1 Starting point: SOA and WSA 3..Problem Description 3.Our solution: WSbSC reference model 1-Introduction 2. 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.

too Several scenarios are possible .Problem Description 3.3 Service Implementation 4.2 WSbSCWSbSC-RM 3.-Related work 5. status...-Conclusions.1 Starting point: SOA and WSA 3. 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.Our Solution 3.Our solution: WSbSC general scenario 1-Introduction 2.

future work PSC is an XML representation of code. PSC-cert contains: Identity of actors Credentials of actors Metadata of code Policy reference Signatures .-Conclusions.2 WSbSCWSbSC-RM 3. status.Problem Description 3.-Related work 5.Our Solution 3..1 Starting point: SOA and WSA 3.. provided. according to a previously negotiated policy.WSbSC: PSC and PSC-cert 1-Introduction 2. It’s made up of the code itself plus a certificate (PSC-cert): PSC=Code + PSC-cert PSC-cert shows that code was created. validated and generated by trusted identified entities.3 Service Implementation 4.

-Conclusions.Service Implementation with WSbSC 1-Introduction 2.2 WSbSC-RM 3...Problem Description 3. 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 don’t apply code security .3 Service Implementation 4.Our Solution 3.-Related work 5.1 Starting point: SOA and WSA 3.

.2 WSbSC-RM 3.1 Starting point: SOA and WSA 3.3 Service Implementation 4.-Conclusions..Service Implementation with WSbSC General Scenario 1-Introduction 2. status.Our Solution 3. In every case the provider must return the service implementation PSC-cert .-Related work 5. 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.Problem Description 3.

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

rodriguez@unirioja.Thank you emilio.es .

Sign up to vote on this title
UsefulNot useful