Single Sign-On

Por Valeriano Alfonso Rodriguez en Mayo del 2012.

Cliente

Galletas

Sesión

Aplicacion Web

Servidor de Acceso

Vinculado de sesiones

Rebote en el servidor de acceso

Petición de vinculado

Autenticación de usuario

Petición de autenticación

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.

Cliente

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.

Galletas

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).

Sesión

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.

Aplicacion Web

Aparte de sus funciones, debe:

  1. Crear y gestionar una sesión con cada cliente.
  2. Pedir vinculación de su sesión con la del cliente con el servidor de acceso.
  3. Obtener información acerca del usuario; si está autenticado, nombre etc.
  4. Pedir la autenticación de un usuario.

También debe almacenar:

  1. Sesiones abiertas por los clientes.
  2. Cualquier tipo de información que se pueda cachear acerca del cliente.

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.

Servidor de Acceso

Sus funciones son:

  1. Crear y gestionar una sesión con cada cliente.
  2. Vincular sesiones recibidas por las aplicaciones web.
  3. Enviar información a las aplicaciones que así lo requieran.
  4. Realizar la autenticación de usuarios.

También debe almacenar:

  1. Sesiones abiertas por los clientes.
  2. Vinculaciones entre códigos de sesión de cada aplicación con códigos de sesión de los clientes.
  3. Colección de los nombres y sus correspondientes claves secretas de todas las aplicaciones autorizadas.

Vinculado de sesiones

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.

Rebote en el servidor de acceso

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.

Petición de vinculado

La petición de vinculado es una URL, apuntando al servidor de acceso, en la que se especifica:

  1. El nombre del comando, en este caso el comando sería “link” (cmd).
  2. El nombre de la aplicación web (app).
  3. El código de sesión del cliente con la aplicación web (sid).
  4. La URL de retorno (la actual en la que estaba el cliente) (url).
  5. Un código de comprobación (chk).
  1. MD5(“link”+app+sid+url)

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.

Autenticación de usuario

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.

Petición de información

La petición de información es una URL, al servidor de acceso, en la que se especifica:

  1. El nombre del comando, en este caso “info” (cmd).
  2. El nombre de la aplicación web (app).
  3. El código de sesión del cliente con la aplicación web (sid).
  4. Un código de comprobación (chk).
  1. MD5(“info”+app+sid)

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.

Petición de autenticación

La petición de autenticación es una URL en la que se especifica:

  1. El nombre del comando, en este caso “auth” (cmd).
  2. El nombre de la aplicación web (app).
  3. El código de sesión del cliente con la aplicación web (sid).
  4. El nombre del usuario (user).
  5. Un código de comprobación (chk).
  1. MD5(“auth”+app+sid+user+MD5(sid+MD5(password)))

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:

  1. MD5(“auth”+app+sid+user+MD5(sid+passwordHash))