Seguridad en servicios web tipo REST
Archivado en la categoría (Identidad Digital, Seguridad) por Teresa
Publicado el 13-12-2009

Los servicios web que utilizan SOAP para el envío de mensajes han tenido la suerte de contar con la especificación Web Services Security (WS-SEC), la cual les permite incluir tokens de seguridad en la cabecera SOAP.

Mensaje SOAP con WS-SEC

Mensaje SOAP con WS-SEC

Los token de seguridad más comunes en WS-SEC son:

  • Nombre de usuario: token donde se incluye el nombre de usuario y la contraseña, para poder autenticar al usuario.
  • Certificados digitales: token donde se incluye el certificado digital del usuario.
  • Aserciones SAML: token donde se incluye una aserción SAML que incluye información sobre el usuario.

De esta forma, se pueden proteger servicios web clásicos sin ningún problema de interoperabilidad, ya que existen numerosas implementaciones de WS-SEC para casi cualquier tipo de lenguaje de programación.

Para el caso de un escenario donde tenemos servicios web tipo REST, nos encontramos con un gran problema ya que el estándar WS-SEC no puede ser aplicado, ya que al usar peticiones HTTP estándares no existía forma de incluir dichos token de seguridad sin modificar los parámetros de cada petición, y no existe ningún estándar que cubra la necesidad de enviar tokens de seguridad en dicho escenario. Aunque el token de nombre de usuario (o Username Token) de WS-SEC podría mapearse sin muchos problemas al uso de HTTP Auth, si es cierto que no existe ninguna solución si nuestra arquitectura utiliza tokens basados en certificados digitales o aserciones SAML.

Afortunadamente, la semana pasada se publicó un draft a través de la IETF para la autenticación HTTP basada en tokens. Este draft busca dar una solución a la autenticación a través de tokens de OAuth, pero ofrece un modelo genérico que puede ser aprovechado por otro tipo de tokens más clásicos como los comentados más arriba.

Así, basándonos en dicho draft, una forma de proteger nuestros servicios web tipo REST utilizando certificados digitales quedaría tal como describe el siguiente ejemplo:

GET /resource/1 HTTP/1.1
Host: example.com
Authorization: Token token=»h480djs93hd8…yZT4=»,
class=»x509″,
method=»rsassa-pkcs1-v1.5-sha-256″,
nonce=»dj83hs9s»,
timestamp=»137134190″,
auth=»djosJKDKJSD8743243/jdk33klY=»

Donde,
  • token: es el certificado digital del usuario en base 64.
  • class: indica el tipo de token, en este caso si es ‘x509′ significa que es un certificado digital.
  • method: su valor será siempre ‘rsassa-pkcs1-v1.5-sha-256′, ya que de esta forma incluiremos un resumen o hash del mensaje enviado a través de la clave privada del usuario, tal como especifica dicho draft.
  • nonce: es una cadena aleatoria.
  • timestamp: es el timestamp del cliente cuando generó dicha petición.
  • auth: es el resumen o hash calculado usuando la clave privada del usuario.

Para el caso de querer proteger el servicio web tipo REST utilizando aserciones SAML, tendríamos una petición de este estilo:

GET /resource/1 HTTP/1.1
Host: example.com
Authorization: Token token=»h480djs93hd8…yZT4=»,
class=»samlv2.0″,
method=»none»

Donde,
  • token: es la aserción SAML del usuario.
  • class: indica el tipo de token, en este caso si es ‘samlv2.0′ significa que es una aserción SAML.
  • method: su valor será siempre ‘none’.
En este caso, no nos hemos detenido en si la aserción SAML es key-of-holder or sender-voucher, ya que podríamos cambiar el method al disponer el cliente acceso directo al par de claves privadas y públicas del usuario.

Comentarios

Rafa on 19 julio, 2012 at 1:34 pm #

Gracias,

Claro, directo y me ha solucionado la vida.


Escribe un comentario

You must be logged in to post a comment.