Por Valeriano Alfonso Rodriguez en Mayo del 2012.
Rebote en el servidor de acceso
Cuando hay más de una aplicación web en diferentes dominios, las cuales pertenecen a la misma organización/entidad. Surge el problema de la masificación de pares Usuario/Contraseña para un mismo usuario en las diferentes aplicaciones.
Por ello surge la idea de hacer que el usuario acceda a su cuenta una sola vez, y este acceso sea compartido por el resto de aplicaciones web. Cosas como Passport, Facebook Connect u OpenID, implementan diferentes estrategias para conseguir esto.
En este documento se describe un método de los muchos posibles para conseguir unificar todas las sesiones de un mismo cliente en diferentes aplicaciones web, posiblemente también en diferentes dominios.
Definimos como cliente a cada una de las instancias de navegadores web que utilizan las aplicaciones web. Para el correcto funcionamiento de las sesiones es necesario que este navegador soporte galletas/cookies, para poder establecer una galleta de sesión.
Esta definición permite al usuario tener uno o varios clientes con sus respectivas sesiones en las aplicaciones web.
Las galletas son pares clave-valor que permiten almacenar información de forma persistente entre peticiones web, siendo borradas cuando pasa el tiempo de caducidad que tengan establecido.
Estas también son establecidas para el dominio y path dentro de este. Esto quiere decir que en caso de tener una galleta establecida en un dominio (p.e: ejemplo1.com), esta galleta no será accesible desde otro dominio (p.e: ejemplo2.com).
Las sesiones sirven para marcar de algún modo a cada usuario único. De este modo las aplicaciones web pueden diferenciarlo del resto de usuarios entre todas las peticiones. Tanto las aplicaciones como el servidor de acceso tendrán sesiones con el usuario.
Las sesiones se pueden crear estableciendo una galleta para identificar a cada cliente. La galleta contendrá un código único y será establecida solo si no hubiese galleta establecida de antemano.
El código de sesión, así como la fecha de creación, también será guardado en la aplicación web de algún modo, para tener constancia de las sesiones que tienen los clientes y de cuando se deben borrar.
Aparte de sus funciones, debe:
También debe almacenar:
Para su comunicación con el servidor de acceso, tendrá un nombre y una clave secreta que se correspondan con la que tenga el servidor de acceso.
Sus funciones son:
También debe almacenar:
Esto es vincular la sesión del usuario en la aplicación web, con la sesión del mismo usuario en el servidor de acceso. Esto permite que la aplicación web conozca al usuario único con el que está tratando y al servidor registrar todas las sesiones abiertas con cada aplicación.
Para ello y como modo de evitar las restricciones entre diferentes dominios que se aplican a las galletas, utilizamos redirecciones enviando la información dentro de parámetros en las consultas web.
Llamo rebote a las dos redirecciones que hace el cliente. La primera es cuando se accede a la aplicación web por primera vez, una vez obtenido el código de sesión, se redirecciona al cliente hacia el servidor de acceso con una consulta específicamente preparada para que el servidor de acceso conozca qué sesión y de qué aplicación se ha de vincular al cliente. Esta consulta también contiene información sobre la url original, por lo que una vez que el servidor de acceso ha realizado el vinculado, redirecciona al cliente de nuevo a la aplicación web.
Cuando el cliente vuelve a la aplicación web, al disponer de galleta de sesión identificando, no se le vuelve a redireccionar. A partir de este momento las sucesivas comunicaciones con el servidor de acceso las realizará la aplicación web sin afectar al cliente.
La petición de vinculado es una URL, apuntando al servidor de acceso, en la que se especifica:
Para generar el código de comprobación se utiliza el algoritmo MD5, usando toda esa información además de la palabra secreta de la aplicación web.
Una vez que las sesiones de las aplicaciones web están vinculadas con la sesión en el servidor de acceso, las aplicaciones puede realizar más peticiones o acciones al servidor de acceso.
Cualquier aplicación web puede pedir autenticación de un usuario. Esto se hace mediante una petición web con ciertos parámetros especiales. También puede pedir en cualquier momento información sobre el usuario que ha autenticado, o si lo ha hecho.
La petición de información es una URL, al servidor de acceso, en la que se especifica:
Para generar el código de comprobación se utiliza el algoritmo MD5, usando toda esa información además de la palabra secreta de la aplicación web.
La petición de autenticación es una URL en la que se especifica:
El código de comprobación consiste en varias sumas de comprobación encadenadas.
Con esto se consigue una autenticación evitando la transmisión del password en texto plano, cosa que el servidor de acceso tampoco debería tener. Para comparar este código de comprobación se puede usar de parte del servidor: