area closed

Obviamente la seguridad es uno de los requisitos no funcionales más importantes de los servicios que diseñemos. Si los servicios no son públicos, que yo diría que es lo habitual, tenemos que garantizar que sólo aquellos usuarios y/o aplicaciones que tiene permisos para ello pueden invocar a nuestros servicios.

En el caso de los servicios SOAP hay varias opciones, la más sencilla sería con seguridad BASIC de HTTP. Si nos metemos ya en  en los estándares WS-* tenemos toda una “gama” de posibilidades: desde el usernameToken, pasando por certificados, tokens binarios propietarios, etc. etc.

Sin embargo, como siempre, en el caso de servicios REST tenemos más margen de maniobra. En primer lugar, también podemos securizar los servicios mediante la seguridad BASIC. En este caso,  se manda una ristra de caracteres en base64 con el usuario y passwor en una cabecera HTTP. Esta cabecera se envía en cada invocación a los servicios.

Otra opción es generar un token de seguridad (una ristra de ceros y unos), y que sea este token el que se envía cada vez desde el cliente a modo de credencial. Esto implica que cada vez que el cliente solicite un servicio, se valide el token una y otra vez. Por lo tanto, en el lado del servidor necesitamos guardar el token propiamente dicho, o mejor, su valor hash que se compara con el hash del token que envía el cliente.

Necesitamos por lo tanto almacenarlo en algún sitio en el servidor para reutilizarlo en sucesivas invocaciones. En Java por ejemplo se podría guardar en el contexto de la aplicación (se mantiene mientras esté arrancada la aplicación), en un caché alojado en este ámbito con una caducidad. En PHP, por poner otro caso, esto no es posible por lo que habría que grabarlo en base de datos o en fichero… pero ¿por qué no usar la sesión para guardar el token?

Puede parecer un contrasentido, ya que los servicios son sin estado por naturaleza y precisamente la sesión es la implementación del estado de una aplicación web.

En mi opinión, realmente esto no es estado… es decir, tal como yo lo entiendo estado quiere decir que para ejecutar un servicio, es necesario haber ejecutado anteriormente determinado servicio en un orden establecido. Por ejemplo, para pagar en una tienda por internet, hacemos uso de la cesta de la compra, no es posible comprar sin antes haber añadido objetos al carrito.

Si usamos la sesión para guardar el token de seguridad, y por lo que sea (ha caducado la sesión) el cliente no envía el token o no existe la sesión para ese usaurio, el servicio REST puede simplemente devolver un HTTP CODE 401 que indica que necesita las credenciales de seguridad… el frontal de la aplicación redirigirá al usaurio a la página de login y nuevamente volverá a ejecutar los servicios necesarios.

Así pues, y como implementación sencilla (pero efectiva) de la seguridad, podríamos almacenar determinada información en la sesión. El cliente (el frontal de la aplicación) únicamente tendría que enviar al servidor el cookie con el identificador de la sesión. El servidor, comprobaría que en la sesión se encuentra realmente el token o dato de segurida (podría servir por ejemplo el userName y el rol de ese usuario).