Autenticación y Autorización en HTTP

Autorización del Usuario

• Una vez identificado, se comprueba si el usuario y palabra clave enviados son válidos, así como sus restricciones de uso. La lista de usuarios y sus restricciones de uso se encuentra normalmente en una base de datos.
• A este proceso se le conoce como autorización. Si la respuesta coincide, el servidor transfiere el recurso.

Autentificación con HTTP

• Existen múltiples métodos para la autenticación de usuarios.
• El protocolo HTTP provee un mecanismo para la autenticación de un usuario.

Cabeceras: WWW-Authenticate y Authoritation

• Los navegadores se encargan de manejar la petición al usuario por parte del servidor para que se identifique, presentándole un cuadro de diálogo.

Autentificación con HTTP/1.1

• La autentificación Basic (Ya existía en la versión HTTP/1.0).
• La autentificación Digest (Mejora la Basic).

Autentificación Basic

• Codificación simple de 6 bits.

• Une en una cadena el login y password separado por ":"

• Divide la secuencia de bits de la cadena en grupos de 6 bits.

• A cada trozo le asigna una letra (extraída de una alfabeto especial de 64 caracteres).

• El servidor devuelve el mensaje: HTTP/1.1 401 Unauthorized --> WWW-Authenticate: Basic realm="Autentificación perso.. "

• El cliente reenvía el mensaje añadiendo: Authorization: Basic JYnWp4tdG90dHk6T3ch

• Es muy simple. Se puede decodificar en pocos segundos a mano.

Autentificación Digest

• Alternativa mucho más segura que Basic.
• Utiliza algoritmos de 128 bits (MD5) para hallar el compendio del password.

Alternativas a la Autentificación HTTP

• La autentificación con HTTP presenta varias desventajas:

  • No termina la sesión hasta que es cerrado el navegador.
  • No se puede modificar la presentación de la ventana de diálogo, donde se le solicita al usuario que se identifique. Este formulario es manejado por el navegador autónoma mente.

• La otra alternativa es que la aplicación Web se haga cargo de la autenticación, integrándose a la autorización del usuario y al mecanismo de sesiones.

• La presentación se hace a través de formularios HTML.

• Otorga más flexibilidad para modificar el método de autentificación cuando se necesite.

• La comunicación se cifra utilizando HTTPS.

El Protocolo HTTPS

• HTTPS: protocolo que utiliza SSL (o TSL) para transportar mensajes HTTP (puerto 443).
• SSL asegura que la conexión TCP está cifrada, de forma que una tercera parte no puede espiar su contenido.
• Esta ampliamente implementado tanto en los navegadores como en los servidores actuales.
• La URL comienza por "https://".
• Aunque la conexión HTTP es sin estado, la información SSL se puede retener y reutilizar. Cliente y servidor pueden transmitir nuevos mensajes de forma segura utilizando la misma conexión SSL.

El Protocolo SSL (I)

• SSL: Secure Socket Layer.
• Trabaja sobre TCP y debajo de los protocolos de alto de nivel tales como HTTP.

El Protocolo SSL (II)

• Permite:

  • Al cliente SSL, autentificar la identidad del servidor SSL.
    • Utilizando técnicas de criptografía de llave pública, comprueba que el certificado del servidor es válido y ha sido avalado por una autoridad certificadora (CA).
  • Al servidor SSL, autentificar la identidad del cliente SSL.
    • Usando las mismas técnicas.
  • Establecer una conexión encriptada entre ambas máquinas.
    • Encriptación asimétrica RSA (clave pública).
    • Encriptación simétrica.
    • Proveen un alto grado de confidencialidad
  • Asegurar la integridad de los mensajes.
    • Además, la información encriptada es protegida con un mecanismo para detectar si ésta fue alterada durante su tránsito por la red.

Conexiones Persistentes

• Permiten que varias peticiones y respuestas sean transferidas usando la misma conexión TCP.
• Se usan por omisión en HTTP 1.1.
• Si se envía la cabecera "Connection: close", el servidor cierra la conexión después de la respuesta.
• Un servidor puede cerrar la conexión antes de enviar todas las respuestas.
• El servidor cerrará las conexiones inactivas pasado un plazo de tiempo (ej: 30 segundos).

Conexiones con HTTP/1.0

• Crea y cierra una conexión TCP por cada petición/respuesta HTTP.

• No es del todo cierto Connection: Keep-Alive

• Desventajas:

  • Se incrementa la carga para múltiples peticiones al mismo servidor.
  • Establece una nueva conexión TCP para cada objeto
  • La conexión TCP tarda relativamente bastante tiempo en establecerse.
  • Las conexiones keep-Alive dan problemas

• Ventajas:

  • Es fácil de implementar.

Conexiones con HTTP/1.1

• HTTP/1.1 introduce las conexiones persistentes.

• Se realizan múltiples peticiones/respuestas sobre la misma conexión TCP.

• El cliente y el servidor mantienen por defecto abiertas las conexiones con caches y servidores.

• Para que la conexión se cierre (cliente o servidor): Connection: close

• Ventajas:

  • Reduce el número de conexiones y los consiguientes retrasos y gastos de memoria y CPU.

• Desventajas:

  • Es más complejo que el modelo HTTP/1.0

Problemas

• Manejo de la conexiones:

  • Se suele limitar la conexión para un número finito de recursos.
  • Caches y servidores deben mantener sólo un tiempo limitado la conexión abierta, si está inactiva.
  • ¿Cuánto tiempo?

• Las respuestas son servidas en serie, ordenadas de acuerdo a las peticiones (FIFO)

• Problema de bloqueo en la cabeza de la lista.

• Recursos de gran tamaño provocan que los siguientes recursos tarden en servirse, aunque sean de pequeño tamaño.

Cachés

• Almacenan respuestas (susceptibles de ser guardadas) con la intención de reducir el tiempo de respuesta y la carga de la red.

• Necesitan asegurar que los contenidos guardados en la caché son equivalentes a los almacenados en el servidor.

• Dos modelos:

  • Expiración (consistencia débil) --> Reduce las peticiones al servidor.
  • Validación (consistencia fuerte)--> Reduce la cantidad de datos a transmitir.