La seguridad en los servicios web.

La seguridad siempre es un tema importante en cualquier desarrollo de software, y en el caso de los servicios web no es la excepción, pero en muchos casos los desarrolladores tienen sus dificultades implementando los diferentes escenarios requeridos dado la complejidad de los estándares y las herramientas a utilizar.

Para empezar la seguridad en los servicios web se divide en 2 grandes partes:

1. Seguridad a nivel de transporte: en este caso la seguridad está en el canal de comunicación el cual se encriptar usando algún algoritmo previamente acordado entre el emisor y el receptor y se puede identificar por el uso de https en los endpoint de los servicios web. Básicamente encripta el canal de comunicación dejando desprotegidos los mensajes que viajan en su interior. Lo malo que le veo es que los mensajes pueden ser leídos luego de dejar el canal encriptado. Generalmente se utilizan tokens de usuario y contraseña, o UserName Token,  para fines de autenticación.
2. Seguridad a nivel de mensaje: en este caso la seguridad puede requerir o no que el canal de comunicación esté encriptado, pero como tal la seguridad se aplica al nivel del mensaje.
   Se puede:

Firmar los mensajes a partir del uso de llaves públicas/privadas. Esto garantiza que la información o no sea modificada y en caso de que lo sea se identifique fácilmente. La firma se realiza usando la llave privada y puede ser comprobada por cualquiera que tenga la llave pública correspondiente. También garantiza el no repudio de la información enviada.

Encriptar los mensajes a partir del uso de llaves públicas/privadas. La idea aquí es que aunque se capture el mensaje no se pueda leer su contenido si no se tiene la llave privada correspondiente a la llave pública que se usó para encriptar el mensaje.

Estos escenarios se pueden combinar de múltiples formas y eso es lo que hace la suite de WSO2 y por lo tanto la plataforma de seguridad, como pueden ver en la siguiente imagen donde se muestra un listado de los escenarios de seguridad que se brindan en la actualidad.

El escenario más complicado de implementar a mi entender  es el 15, en el cual se usan los estándares WS-Trust y WS-SecureConversation para establecer una conversación en un escenario seguro entre un cliente que desea acceder a un recurso que es Proxiado por el ESB y el ESB debe validar las credenciales contra un servidor de seguridad que emite y valida token STS. Los mensajes intercambiados van firmados y encriptados.

Lo interesante aquí es que mientras los extremos de la conversación no confían entre si todos los mensajes se protegen usando algoritmos asimétricos, pero una vez que se establece la confianza se pasa a una protección usando un algoritmo simétrico. Esto se debe a que el costo computacional de los algoritmos asimétricos es mayor que los algoritmos simétricos.

En esta figura pueden observar los pasos principales que  se siguen en la comunicación entre cada una de las partes.

Para implementar estos escenarios de manera general solo necesitamos la plataforma de integración y la plataforma de seguridad, como pueden ver en la siguiente imagen donde se expone un servicio proxy que implementa internamente un mecanismo de ruteo a 2 servicios, uno asegurado a nivel de  transporte y otro a nivel de mensaje. Se usa el IS en un caso para obtener un STS y en el otro caso para una autorización de grano fino usando XACML.

En otras entradas les iré mostrando ejemplos de cómo exponer servicios que usen estos escenarios y a implementar clientes que consuman estos servicios.

Posted in arquitectura de seguridad, IS, seguridad, servicios web, WSO2