Saltar al contenido

Programación

X.509 – Certificados.

  • admin 

http://es.wikipedia.org/wiki/X.509

En criptografía, X.509 es un estándar UIT-T para infraestructuras de claves públicas (en inglés, Public Key Infrastructure o PKI). X.509 especifica, entre otras cosas, formatos estándar para certificados de claves públicas y un algoritmo de validación de la ruta de certificación. Su sintaxis, se define empleando el lenguaje ASN.1 (Abstract Syntax Notation One), y los formatos de codificación más comunes son DER (Distinguish Encoding Rules) o PEM (Privacy Enhanced Mail).

Contenido

  • 1 Historia y uso
  • 2 Seguridad
  • 3 Autoridad de certificación
  • 4 Certificados
    • 4.1 Estructura de un certificado
    • 4.2 Extensiones de archivo de certificados
    • 4.3 Ejemplo de certificado X.509 y del proceso de validación
  • 5 Tipos de certificados
    • 5.1 Verificación de datos
    • 5.2 Finalidad
  • 6 Véase también
  • 7 Enlaces externos
  • 8 Referencias
    • 8.1 Notas al pie

Historia y uso

X.509 fue publicado oficialmente en 1988 y comenzado conjuntamente con el estándar X.500 y asume un sistema jerárquico estricto de autoridades certificantes (ACs) para emisión de certificados. Esto contrasta con modelos de redes de confianza, como PGP, donde cualquier nodo de la red (no solo las ACs) puede firmar claves públicas, y por ende avalar la validez de certificados de claves de otros. La versión 3 de X.509 incluye la flexibilidad de soporte de otras tecnologías como bridges y mallas. Puede usarse en una web de confianza peer to peer de tipo OpenPGP, pero desde 2004raramente se usa así.

El sistema X.500 nunca se implementó completamente, y el grupo de trabajo de la infraestructura de clave pública de la IETF, comúnmente conocido como PKIX para infraestructura de clave pública (X.509) o PKIX, adaptó el estándar a la estructura más flexible de Internet. X.509 incluye también estándares para implementación de listas de certificados en revocación (CRLs), y con frecuencia aspectos de sistemas PKI. De hecho, el término certificado X.509 se refiere comúnmente al Certificado PKIX y Perfil CRL del certificado estándar de X.509 v3 de la IETF, como se especifica en la RFC 3280.

La forma aprobada por la IETF de chequear la validez de un certificado es el Online Certificate Status Protocol (OCSP).

Seguridad

En 2005, Arjen Lenstra y Benne de Weger demostraron «como usar colisiones de hash para construir certificados que contienen firmas idénticas y que solo difieren en la clave pública», lo cual alcanzaron usando un ataque de colisiones en la función de hash MD5. [1]

En 2007, Marc Stevens, Arjen Lenstra, y Benne de Weger demostraron «cómo usar colisiones de hash para añadir sufijos a dos ficheros diferentes obteniendo firmas idénticas» [2]

Autoridad de certificación

Artículo principal: Autoridad de certificación

Una autoridad de certificación (AC) es una entidad que emite certificados digitales para su uso por terceros. Es un ejemplo de un tercero de confianza. Las ACs son características en muchos esquemas de infraestructuras de clave pública (PKI).

Los certificados raíz de confianza de una organización pueden distribuirse a todos los empleados de manera que ellos puedan usar el sistema de infraestructura de clave pública de la compañía.Navegadores web como Internet Explorer, Netscape/Mozilla y Opera vienen pre-instalados con certificados raíz, de manera que certificados SSL de grandes vendedores que hayan pagado por el privilegio de ser pre-instalados funcionen al instante. En efecto, el propietario del navegador web determina qué ACs son terceros de confianza para los usuarios del navegador web. A pesar de que estos certificados raíz pueden borrarse o deshabilitarse, es muy raro que los usuarios lo hagan.

Existen muchos ACs comerciales que cobran por sus servicios. Instituciones y gobiernos pueden tener sus propias ACs y también existen ACs gratuitas.

Certificados

En el sistema X.509, una autoridad certificadora (AC) emite un certificado asociando una clave pública a un Nombre Distinguido particular en la tradición de X.500 o a un Nombre Alternativo tal como una dirección de correo electrónico o una entrada de DNS.

Estructura de un certificado

La estructura de un certificado digital X.509 v3 es la siguiente:

  • Certificado
    • Versión
    • Número de serie
    • ID del algoritmo
    • Emisor
    • Validez
      • No antes de
      • No después de
    • Sujeto
    • Información de clave pública del sujeto
      • Algoritmo de clave pública
      • Clave pública del sujeto
    • Identificador único de emisor (opcional)
    • Identificador único de sujeto (opcional)
    • Extensiones (opcional)
  • Algoritmo usado para firmar el certificado
  • Firma digital del certificado

Los identificadores únicos de emisor y sujeto fueron introducidos en la versión 2, y las extensiones en la versión 3. Obsérvese que el número de serie debe ser único para cada certificado emitido por una misma autoridad certificadora (tal como lo indica el RFC 2459).

X.509 es la pieza central de la infraestructura de clave pública y es la estructura de datos que enlaza la clave pública con los datos que permiten identificar al titular. Su sintaxis se define empleando el lenguaje ASN.1 (Abstract Syntax Notation One) y los formatos de codificación más comunes son DER (Distinguished Encoding Rules) o PEM (Privacy-enhanced Electronic Mail). Siguiendo la notación de ASN.1, un certificado contiene diversos campos, agrupados en tres grandes grupos:

  • El primer campo es el subject (sujeto), que contiene los datos que identifican al sujeto titular. Estos datos están expresados en notación DN (Distinguished Name), donde un DN se compone a su vez de diversos campos, siendo los más frecuentes los siguientes; CN (Common Name), OU (Organizational Unit), O (Organization) y C (Country). Un ejemplo para identificar un usuario mediante el DN, es el siguiente: CN=david.comin O=Safelayer, OU=development, C=ES. Además del nombre del sujeto titular (subject), el certificado, también contiene datos asociados al propio certificado digital, como la versión del certificado, su identificador (serialNumber), la CA firmante (issuer), el tiempo de validez (validity), etc. La versión X.509.v3 también permite utilizar campos opcionales (nombres alternativos, usos permitidos para la clave, ubicación de la CRL y de la CA,etc.).
  • En segundo lugar, el certificado contiene la clave pública, que expresada en notación ASN.1, consta de dos campos, en primer lugar, el que muestra el algoritmo utilizado para crear la clave (ej. RSA), y en segundo lugar, la propia clave pública.
  • Por último, la CA, ha añadido la secuencia de campos que identifican la firma de los campos previos. Esta secuencia contiene tres atributos, el algoritmo de firma utilizado, el hash de la firma, y la propia firma digital.

[editar]Extensiones de archivo de certificados

Las extensiones de archivo de certificados X.509 son:

  • .CER – Certificado codificado en CER, algunas veces es una secuencia de certificados
  • .DER – Certificado codificado en DER
  • .PEM – Certificado codificado en Base64, encerrado entre «—–BEGIN CERTIFICATE—–» y «—–END CERTIFICATE—–«
  • .P7B – Ver .p7c
  • .P7C – Estructura PKCS#7 SignedData sin datos, solo certificado(s) o CRL(s)
  • .PFX – Ver .p12
  • .P12 – PKCS#12, puede contener certificado(s) (público) y claves privadas (protegido con clave)

PKCS #7 es un estándar para firmar o cifrar datos (ellos lo llaman «sobreado»). Dado que el certificado es necesario para verificar datos firmados, es posible incluírlos en la estructura SignedData. Un archivo .P7C es simplemente una estructura SignedData, sin datos para firmar.

PKCS #12 evolucionó del estándar PFX (Personal inFormation eXchange) y se usa para intercambiar objetos públicos y privados dentro de un archivo.

Un archivo .PEM puede contener certificados o claves privadas, encerrados entre las líneas BEGIN/END apropiadas.

Ejemplo de certificado X.509 y del proceso de validación

Como ejemplo de un certificado X.509, se encuentra aquí una decodificación (generada con openssl) de uno de los certificados viejos de www.freesoft.org. El certificado real tiene un tamaño de alrededor de 1 KB. Fue emitido (firmado) por Thawte (desde que fue adquirido por Verisign), tal como se indica en el campo Emisor. El tema contiene bastante información personal, pero la parte más importante es el nombre común (CN) de www.freesoft.org – esta es la parte que debe coincidir con la terminal que se está autenticando. A continuación viene una clave pública RSA (módulo y exponente público), seguido de la firma, computada tomando un hash MD5 de la primera parte del certificado y cifrándola con la clave privada RSA de Thawte.

Certificate:
   Data:
       Version: 1 (0x0)
       Serial Number: 7829 (0x1e95)
       Signature Algorithm: md5WithRSAEncryption
       Issuer: C=ZA, ST=Western Cape, L=Cape Town, O=Thawte Consulting cc,
               OU=Certification Services Division,
               CN=Thawte Server CA/Email=server-certs@thawte.com
       Validity
           Not Before: Jul  9 16:04:02 1998 GMT
           Not After : Jul  9 16:04:02 1999 GMT
       Subject: C=US, ST=Maryland, L=Pasadena, O=Brent Baccala,
                OU=FreeSoft, CN=www.freesoft.org/Email=baccala@freesoft.org
       Subject Public Key Info:
           Public Key Algorithm: rsaEncryption
           RSA Public Key: (1024 bit)
               Modulus (1024 bit):
                   00:b4:31:98:0a:c4:bc:62:c1:88:aa:dc:b0:c8:bb:
                   33:35:19:d5:0c:64:b9:3d:41:b2:96:fc:f3:31:e1:
                   66:36:d0:8e:56:12:44:ba:75:eb:e8:1c:9c:5b:66:
                   70:33:52:14:c9:ec:4f:91:51:70:39:de:53:85:17:
                   16:94:6e:ee:f4:d5:6f:d5:ca:b3:47:5e:1b:0c:7b:
                   c5:cc:2b:6b:c1:90:c3:16:31:0d:bf:7a:c7:47:77:
                   8f:a0:21:c7:4c:d0:16:65:00:c1:0f:d7:b8:80:e3:
                   d2:75:6b:c1:ea:9e:5c:5c:ea:7d:c1:a1:10:bc:b8:
                   e8:35:1c:9e:27:52:7e:41:8f
               Exponent: 65537 (0x10001)
   Signature Algorithm: md5WithRSAEncryption
       93:5f:8f:5f:c5:af:bf:0a:ab:a5:6d:fb:24:5f:b6:59:5d:9d:
       92:2e:4a:1b:8b:ac:7d:99:17:5d:cd:19:f6:ad:ef:63:2f:92:
       ab:2f:4b:cf:0a:13:90:ee:2c:0e:43:03:be:f6:ea:8e:9c:67:
       d0:a2:40:03:f7:ef:6a:15:09:79:a9:46:ed:b7:16:1b:41:72:
       0d:19:aa:ad:dd:9a:df:ab:97:50:65:f5:5e:85:a6:ef:19:d1:
       5a:de:9d:ea:63:cd:cb:cc:6d:5d:01:85:b5:6d:c8:f3:d9:f7:
       8f:0e:fc:ba:1f:34:e9:96:6e:6c:cf:f2:ef:9b:bf:de:b5:22:
       68:9f

Obsérvese que al final del certificado se encuentra la firma de mismo. Para estampar esta firma, la autoridad certificadora calcula un hash MD5 de la primera parte del certificado (la sección de Data: los datos del mismo más la clave pública) y cifra ese hash con su clave privada, que mantiene en secreto. Ahora supongamos que un cliente se conecta a www.freesoft.org y el sitio le devuelve el certificado anterior, con la intención de probar su identidad. Para validar este certificado, necesitamos el certificado de la autoridad certificadora, que fue el emisor del primero (Thawte Server CA). Se toma la clave pública del certificado de la autoridad certificadora para decodificar la firma del primer certificado, obteniéndose un hash MD5. Este hash MD5 debe coincidir con el hash MD5 calculado sobre la primera parte del certificado. En ese caso el proceso de validación termina con éxito. Si no, la validación no tiene éxito, y no puede asegurarse que el certificado de www.freesoft.org está vinculado con esa clave pública. Dicho de otro modo, es posible que www.freesoft.org no sea quien dice ser. A continuación se muestra el certificado de la CA:

Certificate:
   Data:
       Version: 3 (0x2)
       Serial Number: 1 (0x1)
       Signature Algorithm: md5WithRSAEncryption
       Issuer: C=ZA, ST=Western Cape, L=Cape Town, O=Thawte Consulting cc,
               OU=Certification Services Division,
               CN=Thawte Server CA/Email=server-certs@thawte.com
       Validity
           Not Before: Aug  1 00:00:00 1996 GMT
           Not After : Dec 31 23:59:59 2020 GMT
       Subject: C=ZA, ST=Western Cape, L=Cape Town, O=Thawte Consulting cc,
                OU=Certification Services Division,
                CN=Thawte Server CA/Email=server-certs@thawte.com
       Subject Public Key Info:
           Public Key Algorithm: rsaEncryption
           RSA Public Key: (1024 bit)
               Modulus (1024 bit):
                   00:d3:a4:50:6e:c8:ff:56:6b:e6:cf:5d:b6:ea:0c:
                   68:75:47:a2:aa:c2:da:84:25:fc:a8:f4:47:51:da:
                   85:b5:20:74:94:86:1e:0f:75:c9:e9:08:61:f5:06:
                   6d:30:6e:15:19:02:e9:52:c0:62:db:4d:99:9e:e2:
                   6a:0c:44:38:cd:fe:be:e3:64:09:70:c5:fe:b1:6b:
                   29:b6:2f:49:c8:3b:d4:27:04:25:10:97:2f:e7:90:
                   6d:c0:28:42:99:d7:4c:43:de:c3:f5:21:6d:54:9f:
                   5d:c3:58:e1:c0:e4:d9:5b:b0:b8:dc:b4:7b:df:36:
                   3a:c2:b5:66:22:12:d6:87:0d
               Exponent: 65537 (0x10001)
       X509v3 extensions:
           X509v3 Basic Constraints: critical
               CA:TRUE
   Signature Algorithm: md5WithRSAEncryption
       07:fa:4c:69:5c:fb:95:cc:46:ee:85:83:4d:21:30:8e:ca:d9:
       a8:6f:49:1a:e6:da:51:e3:60:70:6c:84:61:11:a1:1a:c8:48:
       3e:59:43:7d:4f:95:3d:a1:8b:b7:0b:62:98:7a:75:8a:dd:88:
       4e:4e:9e:40:db:a8:cc:32:74:b9:6f:0d:c6:e3:b3:44:0b:d9:
       8a:6f:9a:29:9b:99:18:28:3b:d1:e3:40:28:9a:5a:3c:d5:b5:
       e7:20:1b:8b:ca:a4:ab:8d:e9:51:d9:e2:4c:2c:59:a9:da:b9:
       b2:75:1b:f6:42:f2:ef:c7:f2:18:f9:89:bc:a3:ff:8a:23:2e:
       70:47

Este es un ejemplo de un certificado auto firmado. Nótese que el CN del Emisor y el CN del Sujeto son iguales. No hay forma de verificar este certificado, salvo que se comprueba contra sí mismo. En este caso, hemos alcanzado el fin de la cadena de certificados. ¿Cómo es entonces que este certificado se hace confiable? Simple: se configura manualmente. Thawte es una de las autoridades certificantes raíz reconocida por Microsoft y Netscape. Este certificado ya viene con el navegador web (probablemente pueda encontrarse listado como «Thawte Server CA» en las opciones de seguridad) y es confiable por defecto. Como certificado confiado globalmente de larga vida (nótese la fecha de vencimiento) que puede firmar prácticamente cualquier cosa (nótese la falta de limitaciones), su clave privada correspondiente debe ser una de las más ocultas del mundo.

Tipos de certificados

Hay distintos tipos de certificados, según el criterio que utilicemos de clasificación.1

Verificación de datos

  • Certificados de Clase 1: corresponde a los certificados más fáciles de obtener e involucran pocas verificaciones de los datos que figuran en él: sólo el nombre y la dirección de correo electrónico del titular.
  • Certificados de Clase 2: en los que la Autoridad Certificadora comprueba además el Documento de identidad o permiso de conducir que incluya fotografía, el número de la Seguridad Social y la fecha de nacimiento.
  • Certificados de Clase 3: en la que se añaden a las comprobaciones de la Clase 2 la verificación de crédito de la persona o empresa mediante un servicio del tipo Equifax.
  • Certificados de Clase 4: que a todas las comprobaciones anteriores suma la verificación del cargo o la posición de una persona dentro de una organización.

Finalidad

  • Certificados SSL para cliente: mediante el protocolo Secure Socket Layer, dirigido a una persona física.
  • Certificados SSL para servidor: usados para identificar a un servidor ante un cliente en comunicaciones mediante SSL.
  • Certificados S/MIME : usados para servicios de correo electrónico firmado y cifrado, que se expiden generalmente a una persona física.
  • Certificados para la firma de código: usados para identificar al autor de ficheros o porciones de código en cualquier lenguaje de programación que se deba ejecutar en red (Java, JavaScript, CGI, etc).
  • Certificados para AC (Autoridades Certificadoras): se usa por el software cliente para determinar si pueden confiar en un certificado cualquiera, accediendo al certificado de la AC y comprobando que ésta es de confianza.

Véase también

  • Autoridad de certificación
  • Certificado digital
  • Clave pública
  • CRL
  • Firma digital
  • Infraestructura de clave pública (PKI)
  • Online Certificate Status Protocol (OCSP)
  • PGP

Enlaces externos

  • CAcert.org, Entidad Certificadora administrada por la comunidad
  • Albalia Demo CA Certificados de Prueba
  • Integración corporativa de la confianza (Enterprise Trust Integration), estándares de Servicios Web y demos
  • Safelayer (implementación comercial)
  • Xcarecrows 4 X509 (implementación comercial)

Referencias

Estudio y propuesta de una guía de sintonización de servicios web seguros basados en J2EE. David Comín Roig UPC.

Notas al pie

  1. ↑ http://www.eurologic.es/conceptos/certificados%20digitales.htm

 

WS-Security

  • admin 

Tipicamente siempre hemos trabajado con Soap con la seguridad garantizada mediante encriptación en el tunel o mediante https. Recientemente nos encontramos con que la seguridad se garantiza mediante el uso de los mecanismos mencionados, además del uso de certificados.

Adjuntaré artículos explicativos sobre esta nueva situación.

http://en.wikipedia.org/wiki/WS-Security

WS-Security

From Wikipedia, the free encyclopedia

WS-Security (Web Services Security, short WSS) is a flexible and feature-rich extension to SOAP to apply security to web services. It is a member of the WS-* family of web service specificationsand was published by OASIS.

The protocol specifies how integrity and confidentiality can be enforced on messages and allows the communication of various security token formats, such as SAML, Kerberos, and X.509. Its main focus is the use of XML Signature and XML Encryption to provide end-to-end security.

Contents

  • 1 Features
  • 2 Use Cases
    • 2.1 Transport Layer Security (Without WS-Security)
    • 2.2 End-to-end security
    • 2.3 Non-Repudiation
    • 2.4 Alternative transport bindings
    • 2.5 Reverse proxy/common security token
  • 3 Issues
  • 4 Performance
  • 5 History
  • 6 Associated specifications
  • 7 See also
  • 8 Alternative
  • 9 External links
  • 10 References

Features

WS-Security describes three main mechanisms:

  • How to sign SOAP messages to assure integrity. Signed messages provide also non-repudiation.
  • How to encrypt SOAP messages to assure confidentiality.
  • How to attach security tokens to ascertain the sender’s identity .

The specification allows a variety of signature formats, encryptions algorithms and multiple trust domains, and is open to various security token models, such as:

  • X.509 certificates
  • Kerberos tickets
  • UserID/Password credentials
  • SAML-Assertion
  • Custom defined token

The token formats and semantics are defined in the associated profile documents.

WS-Security incorporates security features in the header of a SOAP message, working in the application layer.

These mechanisms by themselves do not provide a complete security solution for Web services. Instead, this specification is a building block that can be used in conjunction with other Web service extensions and higher-level application-specific protocols to accommodate a wide variety of security models and security technologies. In general, WSS by itself does not provide any guarantee of security. When implementing and using the framework and syntax, it is up to the implementor to ensure that the result is not vulnerable.

Key management, trust bootstrapping, federation and agreement on the technical details (ciphers, formats, algorithms) is outside the scope of WS-Security.

Use Cases

Transport Layer Security (Without WS-Security)

The typical SOAP use case with a communication between trusted peers (using HTTPS) does not need WS-Security at all. It is described in Alternative, and reduces complexity and improves performance.

End-to-end security

If a SOAP intermediary is required, and the intermediary is not or less trusted, messages need to be signed and optionally encrypted. This might be the case of an application level proxy at a network perimeter, that will terminate TCP connections.

Non-Repudiation

The standard method for non-repudiation is to write transactions to an audit trail, that is subject to specific security safeguards. However, if the audit trail is not sufficient, digital signatures may provide a better method to enforce non-repudiation. WS-Security can provide this.

Alternative transport bindings

Although almost all SOAP services implement HTTP bindings, in theory other bindings such as JMS or SMTP could be used; in this case end-to-end security would be required.

Reverse proxy/common security token

Even if the web service relies upon transport layer security, it might be required for the service to know about the end user, if the service is relayed by a (HTTP-) reverse proxy. A WSS-header could be used to convey the end user’s token, vouched for by the reverse proxy.

Issues

  • If there are frequent message exchanges between service provider and consumer, the overhead of XML SIG and XML ENC are significant. If end-to-end security is required, a protocol like WS-SecureConversation may reduce the overhead. If sufficient, use only encryption or signing, as the combination of both is significantly slower than the mere sum of the single operations. SeePerformance below.
  • The merging of several XML-schemata like SOAP, SAML, XML ENC, XML SIG might cause dependencies on different versions of library functions like canonicalization and parsing, that are difficult to manage in an application server.

Performance

WS-Security adds significant overhead to SOAP-processing due to the increased size of the message on the wire, XML and cryptographic processing, requiring faster CPUs and more memory and bandwidth.

An evaluation in 2005 [1] measured 25 types of SOAP messages of different size and complexity processed by WSS4J with both WS-Security and WS-SecureConversation on a Pentium 4/2,8 GHz CPU. Some findings were:

  • Encryption was faster than signing
  • Encryption and signing together were 2-7 times slower than signing alone and produced significantly bigger documents.
  • Depending on the type of message, WS-SecureConversation either made no difference or reduced processing time by half in the best case.
  • It took less than 10 milliseconds to sign or encrypt up to an array of 100 kilo bytes, but it took about 100~200 to perform the security operations for SOAP.

Another benchmark in 2006[2] resulted in this comparison:

Security Mechanism Messages/second
WS-Security (X.509) XML Signature & Encryption 352
WS-SecureConversation XML Signature & Encryption 798
Transport Layer Security 2918

History

Web services initially relied on the underlying transport security. In fact, most implementations still do[citation needed]. As SOAP allows for multiple transport bindings, such as HTTP and SMTP, an SOAP-level security mechanism was needed. The lack of end-to-end security because of the dependence on transport security was another factor.

The protocol was originally developed by IBM, Microsoft, and VeriSign. Their original specification[3][4] was published on April 5, 2002, and was followed up by an addendum[5] on August 18, 2002.

In 2002, 2 proposals were submitted to the OASIS WSS Technical Committee[6]: Web Service Security (WS-Security) and Web Services Security Addendum. As a result, WS-Security was published:

  • WS-Security 1.0 was released on April 19, 2004
  • Version 1.1 was released on February 17, 2006

The version 1.0 standard published by OASIS contained a number of significant differences to the standard proposed by the IBM, Microsoft and VeriSign consortium. Many systems were developed using the proposed standard and the differences made them incompatible with systems developed to the OASIS standard.

Some refer to the pre-OASIS specification as the «WS-Security Draft 13»[7], or as the Web Services Security Core Specification. However these names are not widely known and indeed today it is hard to clearly identify whether an application or server is using a pre- or post-OASIS specification. Most forum posts use the keyword «WSSE» to refer to the pre-OASIS version because it mandated the use of a «wsse» XML namespace prefix to the http://schemas.xmlsoap.org/ws/2002/07/secext url (and similar urls of different versions).

The protocol is currently officially called WSS and developed via committee in Oasis-Open.

Associated specifications

The following draft specifications are associated with WS-Security:

  • WS-Federation
  • WS-Privacy
  • WS-Test

The following approved specifications are associated with WS-Security:

  • WS-Policy
  • WS-Trust
  • WS-SecureConversation

See also

  • .NET Web Services Enhancements
  • List of Web service specifications (WS-*)
  • SAML
  • WS-I Basic Security Profile
  • Web service
  • X.509
  • XACML
  • XML Encryption
  • XML firewall

Alternative

In point-to-point situations confidentiality and data integrity can also be enforced on Web services through the use of Transport Layer Security (TLS), for example, by sending messages over https. WS-Security however addresses the wider problem of maintaining integrity and confidentiality of messages until after a message was sent from the originating node, providing so called end to end security.

Applying TLS can significantly reduce the overhead involved by removing the need to encode keys and message signatures into XML before sending. A challenge in using TLS would be if messages needed to go through an application level proxy server, as it would need to be able to see the request for routing. In such an example, the server would see the request coming from the proxy, not the client; this could be worked around by having the proxy have a copy of the client’s key and certificate, or by having a signing certificate trusted by the server, with which it could generate a key/certificate pair matching those of the client. However, as the proxy is operating on the message, it does not ensure end-to-end security, but only ensures point-to-point security.

External links

  • OASIS Web Services Security TC (Contains links to download specification documents)
  • WS-Security Specification (IBM)
  • WS-I Basic Security Profile
  • Web Services Security Documentation
  • Web Service Security Patterns (Microsoft)
  • WSS4J (WS-Security Java Implementation from Apache)
  • Apache Rampart (WS-Security Java Implementation from Apache Axis2)
  • WSIT Web Services Interoperability Technologies (WSIT) that enable interoperability between the Java platform and Windows Communication Foundation (WCF)
  • python ws-security example

References

  1. ^ Hongbin Liu, Shrideep Pallickara, Geoffrey Fox: Performance of Web Services Security
  2. ^ Francois Lascelles, Aaron Flint: WS Security Performance. Secure Conversation versus the X509 Profile
  3. ^ Bob Atkinson, et. al.: Web Services Security (WS-Security)
  4. ^ Bob Atkinson, et. al.: Web Services Security (WS-Security)
  5. ^ Giovanni Della-Libera, Phillip Hallam-Baker Maryann Hondo: Web Services Security Addendum
  6. ^ OASIS Web Services Security TC
  7. ^ Web Services Security: SOAP Message Security – Working Draft 13