Charla Web Services

Arquitectura de Servicios Web José Miguel Selman G. j [email_address] Conceptos, Aplicaciones, Buenas Prácticas, Actualidad y Tendencias

Temario Introducción Arquitectura de Servicios Web Seguridad en Servicios Web Orquestación Interoperabilidad Un Web Service en 2 minutos Recomendaciones Aplicaciones y Extensiones Semántica Grid Services Portales Rich Internet Applications: Ajax, REST y más …

Presentaciones Cargo/Rol Empresa/Area Expectativas

Acerca de Mí Ingeniero Civíl en Ciencias de la Computación, Universidad de Chile Arquitecto Tecnológico Senior, BEE Concretorías y Sistemas Líder Grupo Usuarios Java de Chile (www.jug.cl) Instructor Cursos Java, Java EE y Arquitectura para Sun Microsystems Certificaciones Sun Certified Java Programmer Sun Cerified Business Component Developer Sun Certified Web Component Developer Sun Certified Enterprise Architect Profesor Part-Time Universidad de Chile

Introducción La Web fue originalmente diseñeada para compartir documentos Sirve muy bien este propósito: Información compartida: Es una librería de contenido Permite realizar comercio electrónico Factores de éxito Pocos estándares: HTTP+ HTML Modelo de interacción construido realizando pocos supuestos sobre la plataforma computacional. Ubicuidad: E star en la Web y poder ser encontrado

Pero ha evolucionado… Web Web 2.0 ¿Web 3.0? ?

Motivación Hoy, la Web está en todas partes, por lo que hay mucho más que podemos hacer Centro de negocios electrónicos E-commerce automatizado Integración de procesos de negocio Posibilidad de compartir recursos. (Grid Computing) Portales de Agregación de Información … Las soluciones ad-hoc y propietarias han demostrado no ser lo suficientente eficientes Objetivo: Permitir interacciones entre sistemas distribuídos en la Web

Evolución computación distribuída (Hacia Servicios Web) * Fuente: “J2EE Web Services on BEA Weblogic”, Anjali Anagol-Subbarao E-Mail EDI RPCs Corba COM XML SOAP WSDL WS-Stack RMI 1997 1990 1970 2000 1980 (*)

Definiendo Servicios Web “ A Software System designed to support Interoperable machine-to-machine interaction over a network” W3C Características Independientes de la Plataforma Diseñados para apalancar tecnologías existentes Soporte para varios lenguajes de programación Tres estándares SOAP + UDDI + WSDL

WS como Componentes Remotos Proveen mecanismos para ejecutar operaciones remotas de forma similar a: CORBA RMI RPC DCOM La diferencia principal: Apalancamiento de tecnologías y protocolos maduros y estándares de Internet (HTTP, XML, …) Librerías en muchos lenguajes de programación

Quién es Quién Web Services Interoperability Organization Basic Profile, Attachments Profile, … www.ws-i.org Internet Engineering Task Force HTTP, FTP, … www.ietf.org Advancing Open Standards for the Information Society UDDI, WS-Security, WS-*, … www.oasis-open.org World Wide Web Consortium SOAP, WSDL www.w3c.org

Quienes aparecen siempre… Y muchos otros…

Características de los Servicios Web Objetivos Permitir interoperabilidad universal Adopción masiva, ubicuidad, rendimiento Soportar una arquitectura orientada a Servicios (SOA) Soportar eficientemente ambientes abiertos (Web) y cerrados (corporativos)

Características de los Servicios Web Objetivos derivados Conocer con precisión cuales son los Servicios ofrecidos por un proveedor, junto con la descripción de su interfaz Utilizar un estándar que permita comunicar aplicaciones independiente de la plataforma

Características de los Servicios Web Objetivos (+ técnicos) Tener un protocolo universal para la comunicación entre aplicaciones Basar la comunicación en los protocolos de internet (en especial HTTP) Estandarizar los mensajes a enviar, ya sea un documento a procesar remotamente o la invocación de un comando

Características de los Servicios Web Requerimientos Basado en estándares Muy buen soporte es crítico Se asume una muy pequeña infraestructura Sólo un pequeño número de estándares debe ser implementado. Se enfoca en MENSAJES y DOCUMENTOS , no en componentes de Software

Características de los Servicios Web Servicio Web Es una arquitectura de computación distribuída Usa sus propias interfaces, protocolos y servicios de registro, para que distintas aplicaciones de distintas plataformas puedan usar sus procedimientos En constante evolución

Las aplicaciones de Servicios Web son encapsuladas; componentes Web bajamente acoplados que se pueden vincular dinámicamente entre sí

Ciclo de Vida Servicios Registro o Directorio Proveedor del Servicio Consumidor del Servicio 1. Desarrollo servicio e interfaz 5. Desarrollo aplicación cliente 2. Publica servicio en el directorio 3. Busca proveedor de servicio. 4. Listado de proveedores de servicio y descripciones. 6. Requiere Servicio 7. Provee Servicio

Framework de Servicios Web Se describe en términos de: Lo que va en el “fierro” o en los “cables”: Formatos y protocolos . Qué describe lo que va en el “cable”: Lenguajes de Descripción. Qué nos permite encontrar estas descripiones: Descubrimiento de Servicios.

Arquitectura Conceptual Comunicaciones HTTP, SMTP, FTP, JMS, IIOP, … Mensajes Extensiones SOAP Entrega Confiable, Correlación, Transacciones… SOAP Descripciones WSDL Procesos Descubrimiento, Agregación, Coreografía, … XML, DTD, XML Schema S E G U R I D A D A D M I N I S T R A C I Ó N

¿Qué provee la Arquitectura? Encapsulamiento de funcionalidades Sistemas débilmente acoplados Componentes reutilizables Acceso mediante programación Montado “sobre” la Web Comunicación sobre XML

Recordemos que… Web Services WSDL Web Services Description Language SOAP SOAP UDDI Universal Description, Discovery and Integration

WSDL Web Services Description Language Es un documento XML que introduce una gramática para describir puntos de emisión de mensajes (endpoints). Los elementos que permiten describir “endpoints” son: Messages: Referencias a XML Schema que definen las diferente partes de un Mensaje. Operations: Lista de Mensajes involucrados en un flujo de mensaje. Por ejemplo una operación de request-response contiene dos mensajes. PortType: Es el set de flujos de mensajes (Operations), que se encuentran en un “endpoint”, sin detallar el transporte ni la codificación. Binding: Medio de transporte y codificación particular de un PortType. Port: Dirección en la red de un “endpoint” y el binding que lo caracteriza. Service: Colección de “endpoints” relacionados.

WSDL types message portTypes bindings port service Definiciones Abstractas Definiciones Concretas Documento WSDL Declaraciones de Tipos de datos (“dataTypes”) Definición de los mensajes en términos de los “dataTypes” Definición de las operaciones soportadas y los mensajes que forman parte de las mismas Protocolo usado para implementar un “portType” y el formato de los mensajes Asocia una dirección concreta con un “binding” Define los “ports” que proveen el servicio

WSDL Service Port (e.g. http://host/svc) Binding (e.g. SOAP) Interfaz Abstracta portType operation(s) inMesage outMessage Port Binding

SOAP Antes: Simple Object Access Protocol Ahora: Solo SOAP Es un protocolo liviano para el intercambio de información en ambientes distribuídos y descentralizados

Introducción : SOAP No hace todo lo que hace CORBA, RMI o alguna de las arquitecuras de Computación Distribuída anteriores Pero es simple… Estrutura Física: Envelope: Contenedor del mensaje Header: Permite agregar nuevas funcionalidad dependientes de la plataforma Body: Contenedor para la información a transmitir Fault: Contenedor de Mensajes de error

Estructura: Flexible y Extensible Mensaje o PayLoad RPC/Encoded Document/Literal Transporte (HTTP, SMTP, FTP, MQ, etc.) Envelope (XML) Header Body Información Rutas Transacciones Entrega Confiable Seguridad

Extensión: SOAP with Attachments Es posible extender la definición SOAP Puede ser transportado dentro de un MIME MultiPurpose Internet Mail Extension Se preservan las reglas de SOAP Permite el encapsulamiento de compendios de documentos

Extensión : SOAP with Attachments POST /insuranceClaims HTTP/1.1 Host: www.risky-stuff.com Content-Type: Multipart/Related; boundary=MIME_boundary; type=text/xml; start="<claim061400a.xml@claiming-it.com>" Content-Length: XXXX SOAPAction: http://schemas.risky-stuff.com/Auto-Claim Content-Description: This is the optional message description. --MIME_boundary Content-Type: text/xml; charset=UTF-8 Content-Transfer-Encoding: 8bit Content-ID: <claim061400a.xml@claiming-it.com> <?xml version='1.0' ?> <SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"> <SOAP-ENV:Body> <claim:insurance_claim_auto id="insurance_claim_document_id" xmlns:claim="http://schemas.risky-stuff.com/Auto-Claim"> <theSignedForm href="cid:claim061400a.tiff@claiming-it.com"/> <theCrashPhoto href="cid:claim061400a.jpeg@claiming-it.com"/>  </claim:insurance_claim_auto> </SOAP-ENV:Body> </SOAP-ENV:Envelope> --MIME_boundary Content-Type: image/tiff Content-Transfer-Encoding: base64 Content-ID: <claim061400a.tiff@claiming-it.com> ...Base64 encoded TIFF image... --MIME_boundary Content-Type: image/jpeg Content-Transfer-Encoding: binary Content-ID: <claim061400a.jpeg@claiming-it.com> ...Raw JPEG image.. --MIME_boundary--

UDDI Universal Description, Discovery and Integration Es un documento XML que describe un negocio y los servicios que ofrece La idea es buscar la compañía que ofrece un servicio requerido, ver sus características y posiblemente contactar al encargado Páginas Amarillas de SW, pero con páginas blancas, amarillas y verdes

UDDI Estándar de facto para la publicación y descubrimiento de Servicios Web Nace de la necesidad de compartir WS internos Pretende “divulgar y publicitar” los WS en Internet Puede ser usado en Intranets Dos especificaciones: API (herramientas para publicar y consultar) Data Structure (definiciones y codificaciones)

UDDI Codificación: businessEntity: Datos del proveedor del servicio businessService: Categorización basada en negocios o tipos de servicio tModel: Detalles técnicos (gralmente WSDL), pero la idea es independizarse de la implementación. Identificados con UUID, “identificador único universal” … (Bueno, casi…)

Problemas UDDI Los estándares que componen la arquitectura de Servicios Web están diseñados para proveer descripciones del mecanismo de transporte (SOAP), y las interfaces utilizadas (WSDL). Sin embargo estas características no permiten lograr una automática localización de Servicios Web en base a las capacidades que poseen y las funciones que cumplen. UDDI intenta describir Servicios Web, mediante un directorio jerárquico de negocios, que a través de una serie de atributos, permite navegar por una jerarquía clasificada de negocios que poseen servicios. Pero tampoco es capaz de representar las capacidades de un Servicio Web, por lo tanto no entrega herramientas adecuadas para buscar servicios en base a lo que proveen. Aún más, la búsqueda sólo permite como entrada palabras clave o keywords, lo que lleva a recibir resultados amplios y con una muy baja o nula relación. Un Servicio Web puede existir en distintos repositorios UDDI, con distintos identificadores. No existen protocolos de comunicación estandarizados entre directorios, que permitan manejar una sincronización de servicios publicados. Además, un mismo servicio puede ser categorizado con atributos completamente distintos en dos directorios UDDI. Cabe recordar que la experiencia práctica en el uso de directorios UDDI públicos (un directorio privado es siempre más riguroso), muestra que existe un gran número de descripciones de Servicios Web incompletas, erróneas o mal clasificadas. Un caso típico es encontrar Servicios Web publicados en un directorio, que ni siquiera cuentan con atributo que indique donde encontrar la descripción WSDL del servicio.

En Resumen: ¿Qué va en el cable hasta ahora? La integración en Internet necesita un lenguaje XML messaging protocol sobre HTTP: SOAP Dentro de organizaciones la integración debe permitir alternar entre: CORBA, RMI, … Mensajería Métodos o Servicios locales SOAP Seguridad Attachments Confiabilidad Ruteo Transacciones Contexto W3C

Piezas Faltantes: WS-* Seguridad (WS-Security) Logging, credenciales WS-Trust, WS-SecureConversation, … Transactions (WS-Transaction) WS-AtomicTransction, … Calidad de Servicio ( WS-ReliableMessaging ) Garantías de la puntualidad Operaciones asincrónicas Coordinaciones, Workflow …

Seguridad como un habilitador Integración de Aplicaciones EAI CRMs ERPs B2C, B2B, etc. Automatización de Procesos de Negocio Portales de Agregación de Información …

Arquitectura General Aplicaciones Empresariales Clientes Servidor Web Servidor App. Servidor App. Servidor App. Acceso Datos Conectores a Sistemas Legacy Bases de Datos Seguridad Back-end Seguridad Mainframe Seguridad RDBMS etc. Seguridad Middleware Roles Seguridad Componentes Criptografía etc. Seguridad Perímetro Firewalls/VPNs Criptografía Seguridad Servidores Web Detección de Intrusión etc. Plataformas Predominantes: J2EE y .NET

¿De qué debemos proteger nuestras aplicaciones? Violación de Confidencialidad Violación de Integridad Ataque de Repetición

Ataques Aplicaciones Ataque del Intermediario (conocido como “Man in the Middle”)

Ataque típicos Aplicaciones Web Manipulación de parámetros http://www.sitio.com/listadoProductos.do?maxResults=100 ¿maxResults=999999999? Ataques SQL (SQL Injection ) http://www.sitio.com/listTabla.aspx?orderBy=columna1 SELECT * FROM tabla ORDER BY columna1 Recursos no publicados http://www.sitio.com/documentos/documento1.html ¿http://www.sitio.com/documentos/? ¿http://www.sitio.com/test/? ¿http://www.sitio.com/prueba/? Ataques a los servidores Buffer Overflow … Cross Site Scripting (XSS) Phishing …

Requerimientos de Seguridad Autenticación Autorización Confidencialidad Integridad No repudiación Alta Disponibilidad

Desafíos de Seguridad Servicios Web Seguridad basada en el usuario final Mantener la seguridad al pasar por múltiples Servicios (“nodos”) Abstracción de la seguridad del transporte subyacente

Seguridad a través de múltiples Servicios y múltiples transportes Abstracción de Seguridad del transporte subyacente Seguridad Persistente Usuario Sitio Web Servicio Web HTTP JMS Physical Data Link Network Transport Session Presentation Application Physical Data Link Network Transport Session Presentation Application Contexto de Seguridad 1 Contexto de Seguridad 2 …

Seguridad para Servicios Web Los servicios de seguridad pueden ser provistos por: Capa de Transporte Capa de Mensajería Combinaciones de Ambas Existencia de gran cantidad de especificaciones y alternativas

Interrelación Tecnologías/Especificaciones de Seguridad Servicios Web … TCP/IP Capa de Transporte (HTTP, FTP, SMTP, MQ, etc.) Seguridad Capa de Transporte (TLS/SSL) XML Signature XML Encryption SOAP WS Security SAML XKMS Otras Alto Nivel Infraestructura de Red Frameworks XML Fuente: “Securing Web Services With WS-Security. Demystifying WS-Security, WS-Policy, SAML, XML Signature, and XML Encryption”, Jothy Rosenberg and David Remy

WS-Security Esfuerzo conjunto de IBM, Microsoft y VeriSign En Abril de 2002 publican “Security in a Web Services World: A Proposed Architecture and Roadmap” Hoy mantenida por OASIS Su objetivo es Proveer seguridad a SOAP Se enfoca en la correcta y efectiva aplicación de tecnologías como XML Signature XML Encryption SAML Provee un contenedor para artefactos de seguridad

El encabezado WS-Security Tokens de seguridad Cero, uno ó más tokens de seguridad Usualmente no más de uno Elementos de contenido cifrado con XML Encryption Cero, uno ó más de elementos XML Encryption Estos pueden ser <ReferenceList> <EncryptedKey> Elementos de contenido firmado digitalmente con XML Signature Cero, uno ó más firmas XML Signature Usualmente, si se incluye una firma, esta firma como mínimo alguna parte del cuerpo del mensaje.

Ejemplo Sobre SOAP WS-Security <S:Envelope> <S:Header> <wsse:Security> <wsse:UsernameToken> … </wsse:UsernameToken> <ds:Signature> … </ds:Signature> … <xenc:ReferenceList> … <xenc:DataReference URI=”#body”/> … </xenc:ReferenceList> </wsse:Security> </S:Header> <S:Body> <xenc:EncryptedData Id=”body” Type=”content”> … </xenc:EncryptedData> </S:Body> </S:Envelope>

Algunos ejemplos <wsse:Security> <wsse:UsernameToken> <wsse:Username>jselman</wsse:Username> <wsse:Password>1234</wsse:Password> </wsse:UsernameToken> </wsse:Security> <wsse:Security> <wsse:UsernameToken> <wsse:Username>jselman</wsse:Username> <wsse:PasswordType=”wsse:PasswordDigest”> D2A12DFE8D90FC6… </wsse:PasswordType> <wsse:Nonce>EFD89F06CCB28C89</wsse:Nonce> <wsu:Created>2005-05-08T20:21:23Z</wsu:Created> </wsse:UsernameToken> </wsse:Security>

Opciones de Seguridad Capa de Transporte Servicio de Seguridad Tecnologías Integridad SSL/TLS Confidencialidad SSL/TLS Autenticación Proveedor (Servidor) SSL/TLS Autenticación Consumidor (Cliente) SSL/TLS con autenticación de cliente HTTP Basic HTTP Digest HTTP Attributes SSL/TLS HTTP Basic HTTP Digest

Opciones de Seguridad Capa de Mensajería Servicio de Seguridad Tecnologías Integridad XML Signature S/MIME PKCS#7 Confidencialidad XML Encryption Autenticación del Emisor SOAP (Cliente) XML Encryption username & [password|digest] username & [password|digest] Certificado X.509 Token de Seguridad Kerberos SAML REL Etc.

Comparación Seguridad Según Capa Seguridad de Transporte Seguridad de Mensajería Punto a Punto Destino a Destino Madura, su implementación es relativamente directa Nueva, relativamente compleja con muchas opciones de seguridad No granular, enfoque del todo o nada Muy granular, puede aplicar selectivamente a trozos de mensajes y solamente a los requerimientos o respuestas Dependiente del Transporte La misma estrategia puede aplicarse a distintas tecnologías de transporte

Seguridad Capa de Mensajería Construida sobre modelos maduros Gran cantidad de especificaciones XML Signature, XML Encryption, SAML, XKMS, XACML, … Mayor Fortaleza Flexibilidad Mayor Debilidad Flexibilidad

Composición Paradigma emergente Multiples intentos de estandarización de lenguajes (WSFL, XLANG, BPML, BPEL) Se pueden caracterizar en función de patrones de diseño Comparable a diseñar un workflow

Historia de los estándares de Procesos de Negocio 2000/05 XLang (Microsoft) 2001/03 BPML (Intallio) 2001/05 WSFL (IBM) 2001/06 BPSS (ebXML) 2002/03 BPEL4WS 1.0 (IBM, Microsoft) BPEL4WS 1.1 (OASIS) 2002/06 2003/01 WS-Choreography (W3C) 2003/04 WSCI (Sun et al) WSCL (HP) 2002/08

Servicios Web como procesos de negocio Servicio Web 1 Servicio Web 2 Servicio Web 3 Servicio Web 4 Servicio Web 5 Servicio Web n

Problema Tipo Cliente Servicio de Compra Servicio Crédito Servicio de Inventario Consolidación de Resultados Orden de Compra Check Crédito Reservar Inventario Respuesta Crédito Respuesta Inventario Factura

Desafío de los Procesos de Negocio Comunicación asincrónica coordinada entre los servicios Intercambios de mensaje correlacionados entre los participantes Implementar el procesamiento paralelo de actividades Manipular y transformar data entre participantes de la interacción Soporte para las transacciones y las actividades duraderas de negocio Proporcionar manejo de excepciones consistente

Orquestación vs Coreografía Orquestación Es un proceso de negocio ejecutable que describe un flujo desde la perspectiva y control de un sólo punto de emisión (endpoint) (comúnmente: Workflow) Coreografía Son los visibles y públicos intercambios de mensajes, reglas de interacción y acuerdos entre dos o más puntos de emisión de procesos de negocio

Ejemplo: Orden de compra Orden de Compra Requerimiento de Orden de Compra Ack de recepción Respuesta a la orden de compra Negocio “A” Negocio “ B”

Visto como Coreografía OC Request OC Acknowledgement OC Response Coreografía – Las públicas y visibles interacciones de intercambio de mensajes Proceso Público Negocio A Negocio B Envío OC Recepción OC Ack Recepción respuesta OC Recepción OC Envío OC Ack Envío respuesta OC

Visto como Orquestación Envío OC Recepción OC Ack Recepción respuesta OC Transformación Transformación Desde ERP Hacia ERP OC Request OC Acknowledgement OC Response Orquestación – Es un proceso de negocio privado ejecutable Proceso Privado Business BPEL Workflow

Orquestación y Coreografía juntos Envío OC Recepción OC Ack Recepción respuesta OC Transform Transform Negocio A BPEL Workflow OC Request OC Acknowledgement OC Response Generación Plantilla BPEL Generación Plantilla BPEL Recepción OC Envío OC Ack envíoRecepción Respuesta OC Transform Transform Negocio B BPEL Workflow Dos Workflow BPEL que muestran acuerdo entre negocios Negocio B Business Analyst Tool Negocio A

BPEL Business Process Execution Language Version 1.0 liberada por IBM, Microsoft y BEA agosto 2002 Version 1.1 subida a OASIS Abril 2003 Lenguaje XML para describir procesos de como Servicios Web Convergencia de XLANG (Microsoft) y WSFL (IBM) Consenso corporativo IBM, Microsoft, Oracle, Sun, BEA, SAP, Siebel …

Proposición de BPEL Procesos de negocio portables Construido sobre la infraestructura interoperable de los Servicios Web Gran lenguaje empresarial para procesos de negocio Set de habilidades y lenguaje común para desarrolladores Selección del motor de procesos El estándar lleva a la competencia

Estándares que construyen BPEL Description HTTP,IIOP, JMS, SMTP Transport XML Message SOAP WSDL UDDI Discovery Transactions Coordination WS-Security WS-Reliability Quality of Service Business Processes Context Description Management Orchestration - BPEL4WS Choreography - CDL4WS

Actividades BPEL Actividades <invoke> <receive> <assign> <reply> <throw> <terminate> <wait> Actividades Estruturadas <sequence> <switch> <pick> <flow> <link> <while> <scope>

Partners/socios Aquí se declaran los Servicios Web y los roles utilizados por el proceso Ligado al WSDL del proceso en sí y a los Servicios Web participantes mediante tipos de enlaces de servicio Servicio Crédito Partner 2 Servicio Inventario Partner 3 Partner 1 (el proceso) Servicio Compra

Variables Mensaje enviados y recibidos por partners Persisten en largas interacciones Definidas en los tipos y mensajes WSDL Customer Service Process <variable> <activity> <activity> Persist Persist/ Retrieve Customer Service Persist/ Retrieve Persist/ Retrieve <variable> <A> <B>

En Resumen . . . Compilar Empaquetar Desplegar Partner WSDL 1 WSDL del Proceso Partner WSDL n Escenario BPEL <process> <partners> <variables> <sequence> <flow> </sequence> </process> Servidor de Aplicaciones ejecución BPEL BPEL Compilado

BPEL4People BPEL se centra en coordinación de actividades entre sistemas BPEL4People extiende el concepto permitiendo la integración de personas en los procesos de negocio Casos de excepción Escalamientos … Mantenida por OASIS, Miembros: Adobe, IBM, SAP, Oracle, RedHat y otros … Más información: http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=bpel4people

¿Donde Vamos? La integración requiere de descripciones interoperables entendibles por máquinas La extensión de los lenguajes provee soporte para diferentes niveles de integración entre aplicaciones Servicios Web = SOAP + WSDL + UDDI + … Interfaz Calidad de Servicio Servicio Flujo Público Flujo/Composición Acuerdos WSDL BPEL XML Schema Administración Seguridad

WS-I Web Services Interoperability http://www.ws-i.org/

Es un esfuerzo abierto de la industria dedicado a promover la interoperabilidad de Servicios Web entre plataformas, aplicaciones y lenguajes de programación Es un integrador de estándares para ayudar a los Servicios Web a avanzar de una manera coherente y estructurada Aproximadamente 130 miembros 70% vendedores soluciones, 30% end-user (servicios) Fuerte presencia non-U.S. What is WS-I? WS-I Web Services Interoperability

WS-I, Standards, and Industry WS-I Web Services Interoperability

Permitir interoperabilidad de Servicios Web Integrando Especificaciones Promoviendo implementaciones consistentes Permitiendo una visible representación de conformidad Acelerar el despliegue de Servicios Web Ofrecer guías de implementación y buenas prácticas Entregar herramientas y aplicaciones de ejemplo Proveer de un foro de implementadores donde los desarrolladores puede colaborar Incentivar la adopción de Servicios Web Construir consenso en la industria para reducir los riesgos de adopción temprana Provee de un foro para que los end-users comuniquen requerimientos Aumentar el conocimiento de los requerimientos de negocio WS-I Goals WS-I Web Services Interoperability: ¿Objetivo?

Para end-users Reducir el costo, complejidad, y riesgo de adoptar Servicios Web Acelera la interoperabilidad entre productos and soluciones Ayuda a asegurar que los requerimientos de negocio se cumplan Para vendedores Satisfacer las demandas de los clientes de interoperabilidad cross-vendor Acelerar el time-to-market de desarrollo de nuevos productos Les permite influenciar la industria Para los desarrolladores Aumenta la productividad vía especificaciones, herramientas y buenas prácticas Establece un framework para aumentar la eficiencia de otros desarrolladores Les permite influenciar la industria WS-I Value Proposition WS-I Web Services Interoperability: ¿Objetivos?

Perfiles Set de especificaciones o estandarizción de estandares en una versión específica Guías y convenciones para usar estas especificaciones en formas que aseguren la interoperabilidad Aplicaciones de ejemplo Casos de uso y escenarios basados en requerimientos de clientes Código de ejemplo y aplicaciones construidas en múltiples ambientes Para demostrar la interoperabilidad basada en perfiles Herramientas de Test y documentación Herramientas que prueban las implementaciones de los perfiles para ver el nivel de conformidad Documentación, white papers Deliverables WS-I Web Services Interoperability: ¿Entregables?

Basic Profile Working Group Núcleo de especificaciones. Corazón SW Basic Security Profile Working Group SOAP messaging security, transporte y otras consideraciones de seguridad XML Schema Work Plan Working Group Planificar soluciones apropiadas para solucionar problemas de interoperabilidad de XML Schema WS-I Web Services Interoperability: Detrás de cámaras…

Sample Applications Working Group Ilustrar buenas prácticas para implementar en múltiples plataformas Testing Tools Working Group Construye herramientas de pruebas auto administradas para cumplir con la conformidad con perfiles WS-I Requirements Gathering Working Group Captura requerimientos de negocio para conducir las futuras direcciones de los perfiles Current Working Groups WS-I Web Services Interoperability: Detrás de cámaras…

Basic Profile Basic Profile 1.0 and 1.1 Más de 200 problemas de interoperabilidad resueltos; convenciones alrededor de la mensajería, descripción y descubrimiento Simple SOAP Binding Profile 1.0 — Derivado del Basic Profile. Requerimientos relacionados con la serialización de un “envelope” y su representación en el mensaje Sample Applications and Testing Tools for the Basic Profile • Attachments Profile 1.0 Complementa el Basic Profile 1.1 para agregar soporte para el transporte interoperable de datos atachados SOAP with Attachments (SwA) Delivered to Date WS-I Web Services Interoperability: Perfiles

Basic Security Profile Security Scenarios (Working Group Draft) Documentar riesgos de seguridad en Servicios Web interoperables, junto con las correspondientes medidas de mitigación Basic Security Profile 1.0 (Working Group Draft) — Se dirige a la seguridad en el transporte y otras consideraciones de seguridad para los perfiles WS-I — Perfila las especificaciones de OASIS Delivered to Date WS-I Web Services Interoperability: Perfiles

WS-I’s Work to Date Composition/Orchestration Business Process Orchestration Portals Management XML, SOAP XML Schema, WSDL, UDDI, SOAP with Attachments HTTP, HTTPS, Others Invocation Description Transports Composable Service Elements Transactionality WS-Security Reliable Messaging Endpoint Identification, Publish/Subscribe Messaging Additional Capabilities WS-I Web Service Interoperability

Resumen Reduce el costo, complejidad y riesgo Provee confianza en la interoperabilidad Guías de implementación comunes Aumenta la productividad y acelera el time to market Facilita la colaboración, interna y con socios Permite a las compañías enfocarse en el valor agregado no en la “plomería” Simplifica las decisiones de compra El logo WS-I identifica conformidad. Business Value of WS-I Conformance WS-I Web Service Interoperability

Recapitulando … Ventajas Web Services Desarrolladores no se preocupan mas por la infraestructura Reducción de costos en el ciclo de desarrollo de software por la alta reutilización de componentes Proveedores de Servicios Acceso personalizado en diversos medios y dispositivos Interoperabilidad Multiplataforma

Recapitulando … Posibilidades Actualmente Servicios Web Necesitan de una codificación estática de su construcción, invocación y conexiones mutuas Nula reacción a cambios: proveedor, interrupción, modificación de la interfaz Mantenimiento es costoso No permite optimizar, buscar el servicio que más se acomode a mi realidad y de menor costo

Aplicaciones/Frameworks Practicamente todas las plataformas tienen soporte para Web Services Java Axis - Axis2 JAX-RPC, JAX-WS (J2EE y JEE) Metro .NET SAP (mySAP) Oracle …

Java EE: Un servicio en 2 minutos Java EE 5 NetBeans 6.1 GlassFish v2

Recomendaciones y Buenas Prácticas

Exponer sólo lo necesario Cambios en los servicios Si cambia la implementación no hay problema, pero Si cambia la interfaz… No siempre conocemos a todos los consumidores de un servicio Efecto Ripple

Recomendaciones y Buenas Prácticas Las Buenas Prácticas relacionadas a XML también son aplicables a Web Services Partir de a poco Proyectos pequeños Silver Bullet / Golden Hammer Usar estándares maduros Portabilidad Evitar extensiones propietarias y versiones no finales Seguir las recomendaciones de interoperabilidad (WS-I)

Definir interfaces estables Los mismos principios de diseño de software y arquitectura son aplicables a Servicios Web La calidad de las interfaces es clave Completas y autocontenidas… Nombres descriptivos Debiera ser fácil interpretar lo que hace un servicio y los parámetros que recibe Ej: consulta(int param1, String param2) Convenciones de nombres Los beneficios no se perciben hasta avanzada la construcción de un sistema Top-Down  Partir por la interfaz

Separación de Responsabilidades Principio “Separation of Concerns” http://en.wikipedia.org/wiki/Separation_of_concerns public boolean esFeriadoLegal(Date date) throws UnauthorizedException { ExecutionContext ec = getCurrentExecutionContext(); SOAPDocument request = ec.getCurrentMessage(); String username = getUsernameFromSoapMessage(request); String password = getPasswordFromSoapMessage(request); if ( !canUseService(username, password) ) { throw new UnauthorizedException(“Access Denied for given credentials”); } boolean isFeriado = AccesorBaseDeDatos.getFeriado(date); return isFeriado; } Código Servicio

Conocer las Limitaciones Considerar la carga adicional que recibirá un servidor al ser expuesto como Servicio Web

Identificar, Clasificar y Catalogar Identificar y Clasificar Servicios Verticales: Funcionalidad Horizontales: Transversales a nuestras arquitecturas Mantener un directorio de Servicios Ubicación Características Responsable ¿Clientes? Versionamiento Gobernancia

La importancia de un Repositorio Mantener un directorio debe ser una actividad obligatoria Fomenta la correcta catalogación Fomenta el descubrimiento y reutilización No nos olvidemos de que siempre que distribuimos una aplicación introducimos: Potencialmente más puntos de falla La no disponibilidad de un servicio puede afectar a la disponibilidad de nuestros sistemas Facilita la administración y monitoreo Acciones ProActivas

Cuando evitar Web Services Pueden no resultar siempre la mejor alternativa Sólo utilizar cuando aporte algún valor ¡No todo es un Servicio! ¿Validación de RUT? Considerar Efectos de codificación y decodificación XML Existen aceleradores de Hardware Efectos de Overhead de Llamadas Remotas Efectos de Participación con el resto de la infraestructra Transacciones Administración … .

Ontología OWL-S Semantic Mark Up For Web Services Ontología Términos Relaciones entre ellos Describir un dominio de aplicación concreto sin ambigüedades Arquitectura Perfil (Profile) ¿ Qué hace el servicio? Modelo (Model) ¿ Cómo usar el servicio ? Implementación (Grounding) ¿ Cómo acceder al servicio ?

OWL-S: Profile PERFIL: ¿Qué hace el servicio? Conceptualmente Lo que se logra Limitaciones Calidad Requerimientos En concreto Datos proveedor Categoría Parámetros Entrada y Salida Tipos

OWL-S: Model MODELO: ¿Cómo usar el servicio? Detalla contenido semántico de los requerimientos Cómo preguntar y para el servicio que ocurre luego de su invocación Esta descripción puede ser utilizada por agentes Especificación de operaciones Simples o compuestas

OWL-S: Grounding IMPLEMENTACION: ¿Cómo acceder al servicio? Protocolo Mensajes Puertos … Enlace a descripción funcional WSDL

OWL-S: Relación WSDL Más información: http://www.w3.org/Submission/2004/SUBM-OWL-S-20041122/

Discusión OWL-S ¿Aplicable hoy?

Grid Services Open Grid Services Architecture (OGSA) La tecnología grid se ha vuelto muy popular En 2003 fue declarada por el MIT como una de las 10 tecnologías emergentes que cambiarán el mundo. La palabra ”grid” empieza a aparecer por todos lados, todo el mundo habla de ello

Grid Services ¿Qué es el Grid? “ Mientras que la Web es un servicio para compartir información a través de Internet, el Grid es un servicio para compartir potencia de cálculo y capacidad de almacenamiento a través de la red” Esta forma de compartir se realiza abstrayendo/virtualizando los recursos que participan en una infraestructura grid, de manera que para el usuario final actúan como un único y potente “computador” Los teóricos del grid computing entienden que el objetivo final de la tecnología grid es crear una infraestructura cuyo ámbito sea todo Internet Integrando todos los heterogéneos recursos computacionales que existen alrededor del mundo

Grid Services Aclaraciones El Grid NO es una mejora/ampliación de Internet (no están al mismo nivel) El Grid NO es un proyecto (es una tecnología) El Grid NO es un cluster de ordenadores (en un grid puede haber integrados muchos o ningún cluster) El Grid toma el nombre de su analogía con la red eléctrica (inglés ” power grid ”):

Grid Services: Grid Middleware El Grid es posible gracias al ”grid middleware” El software que permite la integración de todos los distintos tipos de recursos que participan en él. ¿software especial? ¿ middleware ? Definición de middleware (Wikipedia): ”En un entorno de computación distribuida, el middleware se define como la capa de software que se encuentra entre el sistema operativo y las aplicaciones en cada host/máquina que participa en el sistema” Globus Toolkit http://www.globus.org/toolkit/

Grid Services (Middleware) Finalidad: virtualización de los recursos de computación Funcionalidad: Asignación eficiente de recursos Ejecución de trabajos y posterior transferencia de resultados Almacenamiento, registro y posterior localización y acceso a datos Proveer mecanismos de seguridad: autenticación, autorización... Monitorización El grid middleware se construye mediante servicios grid (” grid services ”), que a su vez están basados en la tecnología de Servicios Web

Infraestructura Grid: Vista Conceptual Más Información: http://www.globus.org/ogsa/

Portales y WSRP http://www.ibm.com/developerworks/webservices/library/ws-wsrp/

Otra Dimensión de Servicios Web: Portales y WSRP Mantenida por OASIS Web Services for Remote Portlets Información + Presentación Look & Feel provisto por el portal Mejor reutilización aplicaciones Web

WSRP: Productores y Consumidores

Rich Internet Applications: Ajax, REST y más …

Rich Internet Applications Interfaces de Usuario “Ricas” Pilar Fundamental de la Web 2.0 Mejorando la experiencia en aplicaciones Web acercándolas al Desktop Drag & Drop Autocompletación Expasión (Arboles, etc.) … Cambio de Paradigma Evolución de un modelo Síncrono A un modelo asíncrono

Modelo Síncrono Actividad de Usuario Actividad de Usuario Actividad de Usuario Procesamiento en Servidor Procesamiento en Servidor

Modelo Asíncrono Browser Motor AJAX Input Usuario 1 Input Usuario 2 Render Respuesta 1 Render Respuesta 2 Procesamiento en Servidor Procesamiento en Servidor

AJAX Plataforma para RIA A synchronous J avascript A nd X ML XMLHttpRequest, MSXML Registro de Callbacks Uso de DOM DHTML Y muchos más…

REST RE presentational S tate T ransfer Alternativa a SOAP Recursos Tienen URIs http://www.boeing.com/aircrafts/767 http://www.travelsite.com/Chile/Santiago/Hotels/Marriott Clientes interactúan vía verbos HTTP GET: Para leer PUT: Para reemplazar DELETE: Para eliminar POST: Para acciones

JSON J ava S cript O bject N otation

Otras Plataformas RIA www.javafx.com silverlight.net www.adobe.com/es/products/flex/ www.adobe.com/es/products/air/ Y muchas más…

Bibliografía “ Web and Grid Services. Architectures and Technologies”, Savas Parastatidis, North-East Regional E-Science Centre “ Describing Web Services using OWL-S and WSDL”, http://www.daml.org/services/owl-s/1.1/owl-s-wsdl.html “ Arquitectura de Servicios Web y Frameworks de Desarrollo”, Rodrigo Frez, Universidad de Chile “ Modularización de los aspectos de seguridad en Servicios Web”, José Miguel Selman G., Universidad de Chile “ Servicios Web y Frameworks de Desarrollo”, José Miguel Selman G., Universidad de Chile

XML Signature Esfuerzo conjunto IETF/W3C Su objetivo es firmar digitalmente: Documentos XML Partes de Documentos XML Objetos Externos Utiliza tecnologías maduras de encriptación asimétrica y generación de hashes SHA1 RSA … Requiere de una infraestructura de llaves públicas para proveer: Identidad No repudiación

Tipos de Firmas XML Signature <Signature> <Reference> <ElementoFirmado> Enveloping <ElementoEnvolvente> <Signature> <Reference> Enveloped <DocumentoXML> <Signature> <Reference> Detached <ElementoDestino>

Canonicalización c14n Consenso común XSLT <OrdenDeCompra> <Productos> <CodProducto> SKU10023 </CodProducto> </Productos> </OrdenDeCompra> <OrdenDeCompra><Productos> <CodProducto>SKU10023</CodProducto></Productos></OrdenDeCompra>

Estructura XML Signature <Signature ID?> <SignedInfo> <CanonicalizationMethod/> <SignatureMethod/> (<Reference> (<Transforms>)? <DigestMethod> <DigestValue> </Reference>)+ </SignedInfo> <SignatureValue> (<KeyInfo>)? (<Object ID?>)* </Signature>

XML Signature: Enveloped <OrdenDeCompra id=” ODC200504251002 ”> <SKU>12345678</SKU> <Cantidad>17</Cantidad> <Signature xmlns=”http://www.w3.org/2000/09/xmldsig#”> <SignedInfo> <Reference URI=” #ODC200504251002 ”/> </SignedInfo> <SignatureValue>…</SignatureValue> <KeyInfo>…</KeyInfo> </Signature> </OrdenDeCompra>

XML Signature: Enveloping <Signature xmlns=”http://www.w3.org/2000/09/xmldsig#”> <SignedInfo> <Reference URI=” #10022334 ”/> </SignedInfo> <SignatureValue>…</SignatureValue> <KeyInfo>…</KeyInfo> <Object> <SignedItem id=” 10022334 ”>Información a ser Firmada</SignedItem> </Object> </Signature>

XML Signature: Detached <Signature xmlns=”http://www.w3.org/2000/09/xmldsig#”> <SignedInfo> <Reference URI=” http://www.jselman.com/imagen.jpg ”/> </SignedInfo> <SignatureValue>…</SignatureValue> <KeyInfo>…</KeyInfo> </Signature>

Recomendaciones Seguridad XML Signature Solamente lo firmado es seguro Especial cuidado con desechos ocurridos por transformaciones Solamente lo que se ve puede ser firmado Por ejemplo si un contrato fue presentado a un usuario mediante el uso de XML y una plantilla XSLT, ambos deben ser firmados (WYSIWYS) Ver lo que es firmado Especial cuidado con referencias a objetos que “deberían” contener cierto elemento.

XML Encryption Posterior a XML Signature La información cifrada es expresada en un formato común XML Trozos de un documento XML pueden ser selectivamente cifrados Utiliza algoritmos y técnicas de encriptación maduras Simétrica Asimétrica Híbrida (llave de sesión) Algunos Algoritmos DES 3DES AES …

Estructura XML Encryption <EncryptedData Id? Type? MimeType? Encoding?> <EncryptionMethod/>? <ds:KeyInfo> <EncryptedKey>? <AgreementMethod>? <ds:KeyName>? <ds:RetrievalMethod>? <ds:*>? </ds:KeyInfo> <CipherData> <CipherValue>? <CipherReference URI?>? </CipherData> <EncryptionProperties>? </EncryptedData>

Ejemplo XML Encryption <purchaseOrder> <Order> <Item>book</Item> <Id>123-958-74598</Id> <Quantity>12</Quantity> </Order> <Payment> <CardId> 123654-8988889-9996874 </CardId> <CardName>visa</CardName> <ValidDate>12-10-2004</ValidDate> </Payment> </purchaseOrder> <PurchaseOrder> <Order> <Item>book</Item> <Id>123-958-74598</Id> <Quantity>12</Quantity> </Order> <EncryptedData Type='http://www.w3.org/2001/04/xmlenc#Element‘ xmlns='http://www.w3.org/2001/04/xmlenc#'> <CipherData> <CipherValue>A23B45C564587</CipherValue> </CipherData> </EncryptedData> </PurchaseOrder>

XKMS XML Key Management Specification Infraestructura de llave pública (PKI) Repositorio de credenciales Asociación a identidades Ventajas Complejidad reducida para los clientes Facilita la codificación Administración de la confianza centralizada … PKI Servicios Web XKMS Aplicaciones

SAML Security Assertion Markup Language Especificación mantenida por OASIS Transportador de identidades “ Confianza Portable” Requiere preestablecimiento de confianza entre los dominios Potencial uso para herramientas de Single Sign-On Aserciones en formato XML Autenticación Atributos Autorización ¡Se pueden firmar con XML Signature!

Aserciones SAML Autenticación El Sujeto S fue identificado con el método M a la hora T . Los métodos de autenticación soportados Contraseña Ticket Kerberos Contraseña Remota Segura (RSP) Token de Hardware Certificado de Cliente SSL Llave Pública en un contenedor X.509 Llave Pública PGP Llave Pública SPKI Llave Pública XKMS Firma Digital XML Signature Atributos El sujeto S posee los siguientes atributos: Atributo 1 : a Atributo 2 : b … Atributo n : n Este tipo de información esta típicamente contenida en servidores LDAP. Autorización Al sujeto S se puede autorizar el acceso tipo A sobre el recurso R dada la evidencia E .

Ejemplo Aserción de Autenticación <saml:Assertion MajorVersion=”1” MinorVersion=”0” AssertionID=”10.254.1.101.12345” Issuer=”jselman.com” IssueInstant=”2005-05-07T22:02:00Z”> <saml:Conditions NotBefore=”2005-05-07T22:02:00Z” NotAfter=”2005-05-07T22:09:00Z” /> <saml: AuthenticationStatement AuthenticationMethod =”password” AuthenticationInstant =”2005-05-07T22:02:00Z”> <saml:Subject> <saml: NameIdentifier SecurityDomain=” jselman.com ” Name=” José Miguel ” /> </saml:Subject> </saml:AuthenticationStatement> </saml:Assertion>

Arquitectura SAML SAML Aserción de Autenticación Aserción de Atributos Aserción de Autorización Autoridad de Autenticación Autoridad de Atributos Punto de Decisión de Políticas (PDP) Recolector de Credenciales Entidad de Sistema Punto de Hacer Valer Políticas (PEP) Requerimiento Aplicación Política Política Política

Ejemplo XML Encryption <Alumno> <Nombre>José Miguel Selman</Nombre> <AñoIngreso>1999</AñoIngreso> <Matricula> <EncryptedData id=” matricula ” Type=”http://www.w3.org/2000/09/xmldsig#content”> <EncryptionMethod Algorithm=”…”/> <CipherData><CipherValue>…</CipherValue></CipherData> </EncryptedData> </Matricula> <NotaExamen> <EncryptedData id=” notaexamen ” Type=”http://www.w3.org/2000/09/xmldsig#content”> <EncryptionMethod Algorithm=”…”/> <CipherData><CipherValue>…</CipherValue></CipherData> </EncryptedData> </NotaExamen> <EncryptedKey> <EncryptionMethod Algorithm=”…”/> <CipherData> <CipherValue>…</CipherValue> </CipherData> <ReferenceList> <DataReference URI=” #matricula ”/> <DataReference URI=” #notaexamen ”/> </ReferenceList> </EncryptedKey> </Alumno>

Token SAML <S:Envelope xmlns:S="..."> <S:Header> <wsse:Security xmlns:wsse="..."> <saml:Assertion MajorVersion="1" MinorVersion="0" AssertionID="SecurityToken-ef912422" Issuer="jselman" IssueInstant="2005-05-14T16:47:05.6228146-07:00" xmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion"> ... </saml:Assertion> ... </wsse:Security> </S:Header> <S:Body> ... </S:Body> </S:Envelope>

Username Token <wsse:Security> <wsse:UsernameToken> <wsse:Username>jselman</wsse:Username> <wsse:PasswordType=”wsse:PasswordDigest”> D2A12DFE8D90FC6… </wsse:PasswordType> <wsse:Nonce>EFD89F06CCB28C89</wsse:Nonce> <wsu:Created>2005-05-08T20:21:23Z</wsu:Created> </wsse:UsernameToken> </wsse:Security>

Token eXtensible Rights Markup Language <S:Envelope> <S:Header> <wsse:Security> <r:license licenseId=”urn:foo:SecurityToken:ab12345”> <r:grant> <r:keyHolder> <r:info> <ds:KeyValue>…</ds:KeyValue> </r:info> </r:keyHolder> <r:possessProperty/> <sx:commonName>José Miguel Selman</sx:commonName> </r:grant> <r:issuer> <ds:Signature>…</ds:Signature> </r:issuer> </r:license> <ds:Signature> <ds:SignedInfo> … <ds:Reference URI=”#msgBody”> … </ds:Reference> … </ds:SignedInfo> … <ds:KeyInfo> <wsse:SecurityTokenReference> <wsse:Reference URI=”urn:foo:SecurityToken:ab12345” ValueType=”r:license”/> </wsse:SecurityTokenReference> </ds:KeyInfo> </ds:Signature> </wsse:Security> </S:Header> <S:Body wsu:Id=”msgBody”> <PictureRequest xmlns=”http://www.jselman.com/pics”> <Picture format=”image/gif”> AxE1TrsRGGH… </Picture> </PictureRequest> </S:Body> </S:Envelope>

Token Certificado X509 <wsse:BinarySecurityToken ValueType=”wsse:X509v3” EncodingType=”wsse:Base64Binary”> NIFEPzCCA9CrAwIBAgIQEmtJZc0… </wsse:BinarySecurityToken>

Token XCBF <S:Envelope xmlns:S="..."> <S:Header> <wsse:Security xmlns:wsse="..."> <wsse:XCBFSecurityToken xmlns:wsse="http://schemas.xmlsoap.org/ws/2002/04/secext" Id="XCBF-biometric-object" ValueType="wsse:XCBFv1" EncodingType="wsee:XER"> <BiometricSyntaxSets> <BiometricSyntax> <biometricObjects> <BiometricObject> <biometricHeader> <version> 0 </version> <recordType> <id> 4 </id> </recordType> <dataType> <processed/> </dataType> <purpose> <audit/> </purpose> <quality> -1 </quality> <validityPeriod> <notBefore> 1980.10.4 </notBefore> <notAfter>2003.10.3.23.59.59</notAfter> </validityPeriod> <format> <formatOwner> <oid> 2.23.42.9.10.4.2 </oid> </formatOwner> </format> </biometricHeader> <biometricData> 0A0B0C0D0E0F1A1B1C1D1E1F2A2B2C2D2E2F </biometricData> </BiometricObject> </biometricObjects> </BiometricSyntax> </BiometricSyntaxSets> </wsse:XCBFSecurityToken> </wsse:Security> </S:Header> <S:Body> ... </S:Body> </S:Envelope>

WS-Security Timestamps <S:Envelope> <S:Header> <wsse:Security> … <wsu:Timestamp> <wsu:Created>2005-05-14T19:31:22Z</wsu:Created> <wsu:Expires>2005-05-14 T19:46:22Z</wsu:Expires> </wsu:Timestamp> … </wsse:Security> </S:Header> </S:Envelope>

Especificaciones WS-* WS-Policy: Define como expresar capacidades y restricciones de políticas de seguridad. WS-Trust: Describe un modelo para establecer relaciones de confianza directa y a través de intermediarios. WS-Privacy: Habilita a los usuarios para establecer sus preferencias de privacidad y a Web Services para establecer e implementar prácticas de privacidad. WS-SecureConversation: Describe como administrar y autenticar intercambios de mensajes entre partes, incluyendo el intercambio de contextos de seguridad y el establecimiento y derivación de llaves de sesión. WS-Federation: Describe la manera de administrar las relaciones de confianza en un ambiente federado heterogéneo, incluyendo soporte para identidades federadas. WS-Authorization: Define como Web Services administran políticas e información de autorización.

Triángulo Seguridad Distribuida

Framework de Seguridad Web Services Especificaciones Base Web Services WS Security WS-Policy WS-Trust WS-Privacy WS-SecureConversation WS-Federation WS-Authorization HOY

Charla Web Services

Más contenido relacionado

La actualidad más candente (19)

Destacado (20)

Similar a Charla Web Services (20)

Último (20)

Charla Web Services