authentication - tutorial - Inicio de sesión: detalles del fondo

inicio de sesión único basado en saml sso (8)

¿Qué sucede cuando inicias sesión en un sitio web?

Sé que las cookies se almacenan y se envía cierta información (¿qué información?) Al servidor ... pero ¿tal vez algún detalle más?

Esa es una pregunta bastante general. Lo que estás haciendo, sobre todo, es establecer algún tipo de credenciales con el sitio en sí. Si tomamos la versión simple, ingresa un nombre de usuario y una contraseña; eso significa que te identificas en el sitio web y luego le muestras un secreto que tú y el sitio web comparten, que nadie más conoce (esperamos). Eso te establece como auténticamente la persona con ese nombre de usuario, y entonces decimos que te has autenticado .

Una vez que lo haya hecho, hay algunas decisiones de diseño que el diseñador del sitio web debe tomar. la mayoría de las personas no desean iniciar sesión en cada página, por lo que el sitio web desea almacenar un poco de información, una credencial , de su parte. Esto significa que puede decir que todavía eres tú. A menudo, como dices, eso es una "cookie", que no es más que un pequeño archivo de texto nombrado con la URL del sitio web. Este archivo es almacenado por el navegador.

En muchos sitios web, como la banca, también desea garantizar que los datos intercambiados no puedan ser interceptados por un tercero. Si es así, establezca una conexión segura utilizando un protocolo conocido como SSL o TLS. Lo que esto agrega a la conexión básica es un intercambio de información que establece una clave de sesión . Esta clave de sesión se usa para encriptar las comunicaciones. Esto generalmente ocurre antes de intercambiar el nombre de usuario y la contraseña, de modo que su contraseña nunca sea visible para un tercero malintencionado.

Debajo de las coberturas, cuando establece una conexión segura, el sitio web envía a su navegador un bloque de datos formateados llamado certificado x509 . Esta es otra forma de autenticación; el certificado habrá sido firmado por un emisor (la autoridad de certificación o "CA") y el navegador puede usar datos almacenados sobre las CA para garantizar que el certificado sea auténtico.

Esto depende completamente de la implementación del sitio web. Incluso el uso de cookies no es obligatorio, pero es muy común.

En la mayoría de los casos, sin embargo, sucede algo como esto:

Envía tu nombre de usuario y contraseña usando un formulario HTML.
El servidor busca el usuario relevante (usando una base de datos)
El servidor verifica si la contraseña coincide con la contraseña que está almacenada en la base de datos junto con el usuario.
Si la contraseña es correcta, el servidor almacenará qué usuario está actualmente activo en la sesión. El identificador de esta sesión se almacena en una cookie, los datos reales de esta sesión (el usuario actual) se almacenan en el servidor bajo este identificador.

Ahora ha iniciado sesión. Permanecerá conectado durante el resto de la sesión:

Cuando solicite otra página del servidor, enviará la cookie con el identificador de sesison.
El servidor carga la sesión usando este identificador. En esta sesión, el usuario actual se almacena, por lo que el servidor sabe qué usuario está conectado.

Cuando inicia sesión en un sitio web, primero se autentica su credencial. Si sus credenciales coinciden, entonces se coloca algo en la sesión (en el servidor) para realizar un seguimiento de quién es usted y acceder a los datos que son suyos sin tener que volver a iniciar sesión. Esto es obviamente inútil en el servidor web a menos que el cliente pueda proporcionar información sobre quién es en cada solicitud. Tenga en cuenta que la "Sesión" se mantiene generalmente en su totalidad en el servidor web, y que el cliente solo tiene una clave que permite el acceso a la sesión.

Recuerde que HTTP en sí mismo es un protocolo sin estado. El estándar HTTP no contiene ningún método para que las solicitudes HTTP mantengan o persistan ningún estado entre solicitudes HTTP individuales. Por lo tanto, el estado generalmente se mantiene completamente en el servidor y solo necesita un método para que el cliente identifique a qué sesión pertenece la solicitud HTTP actual.

Las dos formas comunes en que esto se hace son:

Utilice una cookie (por ejemplo, Apache Tomcat usa la cookie JSESSIONID ) para almacenar algún token de autenticación hash que busque correctamente la sesión web, o
reescribe la URL para que cada solicitud tenga el ID de sesión agregado al final de la solicitud. Aún usando Apache Tomcat como ejemplo, si las cookies están desactivadas, la URL se reescribirá para finalizar con una cadena como " ;jsessionid=.... ". Por lo tanto, cada solicitud, cada HTTP GET y POST (y el resto) terminarán con esta cadena.

Por lo tanto, en cada solicitud que realiza el cliente, la identificación de la sesión se proporciona al servidor web, lo que permite buscar rápidamente el estado persistente para este cliente, permitiendo que HTTP actúe como un protocolo con estado.

¿Qué información se envía al servidor cuando inicias sesión? Cualquier información que haya proporcionado en el formulario de inicio de sesión. Algunos servidores web también rastrean la dirección TCP / IP de la que proviene la solicitud para evitar ataques de secuestro de sesión . Esta suele ser toda la información que necesita el servidor.

Si no permite que su navegador guarde cookies, tendrá que iniciar sesión en el servidor web cada vez que abra su navegador y abra inicialmente la página web del servidor. Sin embargo, si permite que su navegador guarde cookies, entonces muchos servidores le permiten la opción de guardar la cookie (es decir, no solo usar una cookie de sesión) para que cada vez que vaya a una página web del servidor, la cookie persistente lo identificará para que no necesite volver a iniciar sesión. Aquí, la cookie guardará suficiente información, a menudo en una forma encriptada que solo el servidor puede entender, para identificarlo. En este caso, la Cookie no es una ID de sesión simple.

Explicado muy simplemente, lo que sucede se menciona a continuación:

¿Qué entra?

Nombre de usuario
Contraseña

¿Qué pasa dentro?

La contraseña se convierte a su hash
Hash (contraseña) se compara con la tabla de DB o un servicio de directorio (a menos que alguien sea necio, el sitio no guardará su contraseña en texto claro)
Si se autentica, se almacena un token de estado en Session y / o cookie.
- Este token solo puede contener un estado, marcas de tiempo de inicio de sesión, su ID de usuario, tipo de usuario (si corresponde), et al.
- Este token se lee y verifica en cada página a la que accede si esa página requiere que inicie sesión como un tipo de usuario determinado.
Si la autenticación falla , se le redirige a una página que muestra un error que le solicita que vuelva a iniciar sesión.

Lo que sale

Se le redirigirá a su página de perfil personal / a la página a la que accedió y que lo verifica con la ayuda del token.
Además, un Certificado Digital puede aparecer en la imagen si está accediendo a un sitio bancario u otro sitio críticamente seguro

Hay dos formas principales de realizar la autenticación en la web, y algunas formas menos populares que también vale la pena conocer.

El primero es la autenticación HTTP, como se define en RFC 2617 . Cuando solicita una página protegida, el servidor responde con un código de estado 401 , lo que indica que no tiene permiso para acceder al recurso. Además de esto, también envía un encabezado WWW-Authenticate , que instruye al navegador sobre cómo quiere que se autorice. El navegador ve este código de estado y el encabezado, y le solicita los detalles de su autenticación. Cuando los ingresa, su navegador los prepara de acuerdo con el esquema de autenticación específico que especificó el servidor y solicita nuevamente la página, incluido un encabezado de Authorization con los detalles preparados. El servidor verifica estos detalles en su base de datos de usuarios y responde con otro 401 (detalles incorrectos) o la página protegida con un código de estado de 200 para indicar el éxito.

La autenticación HTTP es una de esas características antiguas que los navegadores no implementaron bien para empezar y que nunca se han mejorado realmente. Debido a esto, se ha vuelto mucho más popular que los desarrolladores web implementen la autenticación utilizando cookies para mantener el estado. En este caso, se le presenta al usuario un formulario HTML estándar. Cuando el usuario ingresa sus credenciales en los campos y envía el formulario, el navegador lo codifica y lo envía al servidor de la misma manera que codifica cualquier formulario HTML normal. El servidor verifica las credenciales, y si son legítimas, establece una cookie con un número de ID generado aleatoriamente, junto con una entrada de base de datos / sistema de archivos correspondiente que reconoce ese número de ID como perteneciente a un usuario en particular.

A partir de este punto, cada solicitud que haga el navegador al servidor incluye esta cookie de número de identificación como encabezado HTTP. El servidor reconoce la cookie, busca el número de ID y sabe qué usuario es usted. Cuando elige desconectarse, el servidor envía una respuesta pidiéndole a su navegador que olvide el número de ID, en cuyo caso usted es simplemente otro usuario anónimo.

Una opción menos común es el uso de certificados de cliente SSL. Muchas personas están familiarizadas con la idea de usar SSL para identificar un servidor. Se genera un par de claves criptográficas, firmado por una autoridad de confianza, y se usa para probar que los datos enviados se originaron con el propietario del par de llaves. Sin embargo, lo que muchas personas no conocen es que un cliente puede usar lo mismo para demostrar su identidad a un servidor. Sin embargo, esto es menos conveniente, ya que necesita llevar consigo su certificado si desea usarlo en más de una máquina.

Hay variaciones y opciones menos conocidas disponibles, por supuesto, pero estas son las más destacadas.

Mira, es un poco difícil darte mucha más información que ya tienes aquí; No estoy seguro de por qué quieres darle una recompensa. Una cookie es solo un poco de información con nombre, y puedes poner lo que quieras en ella. Para una sesión, querrías algún tipo de ID de sesión. Hay convenciones para eso, o puede hacerlo usted mismo. Hagas lo que hagas, cuando configuras la cookie, dejas un poco de información en el navegador de la persona que es más o menos así:

mydomain.com: mystuff: this is my stuff, by golly.

Cuando vuelves, recuperas la cookie y la recuperas.

Si desea ver todos los detalles de ese protocolo, eche un vistazo al artículo de Wikipedia .

Érase una vez, en algún lugar de Internet ...

Navegador: "oye, ¿puedo ver esta página web ?, el problema es que no recuerdo haber hablado contigo antes"
Sitio web: "seguro, completa el formulario, necesito tu nombre de usuario y tu contraseña"
Navegador: "Aquí tienes"
Sitio web: "¡Genial! ¡Bienvenido! ¡Aquí está la página! Mira, si quieres más páginas, toma esta ficha y úsala cuando solicites otra".
Navegador: genial Ese sitio me dio una ficha. ¡Lo memorizaré!

Unos minutos más tarde

Navegador: "Ooh, ¿puedo ver esta otra página web? Aquí está mi token"
Sitio web: "Esa ficha se ve bien, hola otra vez, esta es tu página web"

Eso, en esencia, es eso. Para recordar que un usuario ha iniciado sesión, le da al usuario un token que debe presentar con su próxima solicitud. Esto normalmente lo logra el servidor que le dice al navegador que almacene este token en una cookie.

Profundizando: autenticación de la capa de transporte

La forma en que se transmiten las credenciales al servidor y la naturaleza del token que devuelve varían según el método de autenticación empleado.

La mayoría de las implementaciones de servidores web proporcionan la autenticación básica HTTP más simple. Hace que su navegador abra el cuadro de diálogo de inicio de sesión habitual. El "token" es simplemente el nombre de usuario y contraseña de su texto plano base64 codificado. No particularmente seguro.

Un servidor también puede proporcionar Autenticación implícita , lo que evita la transmisión de las credenciales reales; en cambio, el cliente genera un hash de sus credenciales con una sal generada por el servidor. Está diseñado para evitar el rastreo de contraseñas y los ataques de reproducción.

Más profundo aún - autenticación de capa de aplicación

Para una máxima flexibilidad y control, la mayoría de los sitios optan por implementar la autorización en la capa de aplicación en lugar de la capa de transporte HTTP. Esto brinda una mayor variedad de opciones de seguridad. Cualquier sitio que solicite credenciales en una página web (en lugar del cuadro de diálogo de inicio de sesión del navegador) está utilizando un método de autorización personalizado.

Los métodos personalizados variarán enormemente en su interacción inicial, pero casi siempre dan como resultado que el usuario reciba una cookie de sesión que contiene un identificador generado aleatoriamente. El navegador luego presenta automáticamente la cookie con cada solicitud posterior. La aplicación web inspeccionará el valor de la cookie para garantizar que siga siendo válida.

También es posible entregar la autorización a un tercero de confianza, generalmente para proporcionar algún tipo de servicio de inicio de sesión único. En casos como ese, cuando nota que un usuario no está autenticado, los rebotan al proveedor de autenticación. Los autentican y se los devolverán con algún tipo de token que verifique con el proveedor. Shibboleth es un ejemplo de esto. También inició sesión en este mismo sitio utilizando un método similar empleado por OpenID

Otras lecturas

Aquí hay algunas buenas respuestas de una pregunta similar

¡Otras respuestas en esa pregunta brindan aún más enlaces para completar su educación!

Como han mencionado otros, los procedimientos de inicio de sesión varían según la implementación, pero el caso básico (autenticación simple de la aplicación web) utiliza algo así como el siguiente pseudocódigo:

function login(username, password) { user = db->get_user(username) if (user == false) { report_error("Unknown username") exit } if (user->password != hash(password)) { report_error("Incorrect password") exit } // User authenticated, set session cookie session->set_data(''current_user'', user->username) }

Por supuesto, en la mayoría de los casos, se vuelve un poco más complicado que eso, pero cada función de inicio de sesión comienza su vida esencialmente como la anterior. Ahora, si agregamos autologin ("recordarme") a la mezcla, obtenemos algo como esto:

function login(username, password, remember_me) { user = db->get_user(username) if (user == false) { report_error("Unknown username") exit } if (user->password != hash(password)) { report_error("Incorrect password") exit } // User authenticated, set session cookie session->set_data(''current_user'', user->username) if (remember_me == true) { cookie_token = random_string(50) set_cookie(''autologin_cookie'', cookie_token, ONE_MONTH) // Finally, save a hash of the random token in the user table db->update_user(user, ''autologin_token'', hash(cookie_token)) } }

Además de la función para realizar el inicio de sesión automático si hay una cookie presente:

function cookie_login() { cookie = get_cookie(''autologin_cookie'') if (cookie == false) { return false } // Only for demonstration; cookie should always include username as well user = db->get_user_by_cookie(cookie) if (user == false) { // Corrupt cookie data or deleted user return false } // User authenticated, set session cookie session->set_data(''current_user'', user->username) return true }

NOTA: Lo anterior no es un enfoque de ''mejores prácticas'', y no es muy seguro. En el código de producción, siempre debe incluir un identificador de usuario en los datos de cookies, usar varios niveles de aceleración, almacenar datos en inicios de sesión fallidos y exitosos, etc. Todo esto se ha eliminado para hacer que la estructura básica de autenticación sea simple de seguir.

De todos modos, espero que esto sea lo que estabas buscando, koldfyre. No conozco sus antecedentes, pero si no está seguro de cómo funcionan las sesiones y las cookies , debe leerlas por separado, y si necesita detalles más elaborados, solo pregunte.

PD: También puede consultar la pregunta " La guía definitiva para la autenticación del sitio web " para conocer los enfoques de mejores prácticas