java authentication shiro

java - Autenticación Shiro con sessionId o nombre de usuario+contraseña



authentication (1)

Supongo que no necesito sesiones HTTP ni sesiones de Servlet. Shiro tiene su propio administrador de sesión, que es suficiente para mis necesidades. ¿Me equivoco?

No, tienes razón. Es por eso que Shiro es increíble. De la documentation :

El soporte de sesión de Shiro es mucho más sencillo de usar y administrar que cualquiera de estos dos mecanismos [contenedor web o EJB Stateful Session Beans], y está disponible en cualquier aplicación, independientemente del contenedor.

p.ej

Subject currentUser = SecurityUtils.getSubject(); Session session = currentUser.getSession(); session.setAttribute( "someKey", someValue);

citando desde el documento : getSession calls work in any application, even non-web applications

¿Es una buena práctica dar al cliente el sessionId real o debo enviar algún tipo de sessionToken (que se resuelve en sessionId en el lado del servidor)?

Es una mala idea enviar un simple sessionId. Especialmente, si está enviando datos a través de una red no cifrada. NONCE algo como HTTPS o use algo en la línea NONCE .

Y, una nota al margen, si es más de http / s datos POST en lugar de tenerlos en la URL.

¿Cómo inicio sesión en el Asunto usando sessionId (que el cliente debe almacenar localmente)?

¿Quiso decir cómo podría autenticar el tema una vez que tenga la ID de sesión? Usted puede simplemente, desde el documento,

Subject requestSubject = new Subject.Builder().sessionId(sessionId).buildSubject();

¿Hay alguna otra cosa que deba saber antes de realizar este tipo de autenticación?

Sí.

  1. Leer la gestión de la sesión de Shiro
  2. Apóyate sobre el ataque MITM
  3. Acerca de HTTPS y SSL
  4. Algunos en Hash funcionan this , Apache Commons DigestUtils y pueden ser this

Actualizaciones

Acerca de la parte de autenticación del sujeto: ¿hará que el Asunto recién creado sea el sujeto autenticado actualmente? Si no es así, ¿cómo lo hago el tema "actual"?

Si está hablando de un new Subject.Builder().sessionId(sessionId).buildSubject() , no lo hará. Y no sé cómo configurarlo como currentUser para el hilo. El JavaDoc de Shiro dice:

[de esta manera] la instancia de Asunto devuelta no se vincula automáticamente a la aplicación (subproceso) para su uso posterior. Es decir, SecurityUtils.getSubject () no devolverá automáticamente la misma instancia que lo que devuelve el constructor. Es responsabilidad del desarrollador del marco vincular el sujeto creado para su uso continuo si se desea.

por lo tanto, depende de usted cómo vincular el tema en el hilo actual o su uso posterior.

Si estaba preocupado por cómo SecurityUtils.getSubject(); thingy funciona, bueno, en el contexto de un contenedor web, utiliza una cookie simple para almacenar sus datos de sesión. Cuando su solicitud llega a través del filtro Shiro, adjuntó el tema actual para solicitar su ciclo de vida (hilo actual). Y cuando usted como getSubject() simplemente obtiene el Subject de la solicitud. He encontrado un hilo interesante here .

sobre la parte nonce: si me envía algún tipo de hash en lugar de su ID de sesión, no podré descodificarlo para obtener un ID de sesión real (para autorizarlo con eso). ¿Me estoy perdiendo de algo?

Parte de Nonce - es un dolor en el cuello. Ahora repensando, creo que hacer NONCE es una exageración. Déjame explicarte algo, de todos modos,

  1. El usuario inicia sesión por primera vez con su nombre de usuario y contraseña. Establezca userid , nonce (por ejemplo, UUID) y HASH(sessionID+nonce) , llámelo hash1, en el lado del cliente. Decir, en galleta. Guarde este nonce en el lado del servidor, puede estar en la base de datos o en un mapa como user_id <--> nonce,session_id

  2. En una solicitud posterior, asegúrese de que pasa el userid , nonce y el HASH .

  3. En el lado del servidor, lo primero que hará es validar la solicitud. Obtenga el sessionId y el nonce almacenados en el hashmap o en la base de datos según el user_id de user_id que envió el cliente. Cree un hash, HASH (sessionId_from_db + nonce_from_db), llámelo hash2.

  4. Ahora, si hash1 coincide con hash2, puede validar la solicitud y, como ha guardado el ID de sesión actual en el lado del servidor, puede usarlo. Al completar la solicitud, establezca un nuevo nonce en la cookie y en el lado del servidor.

Si pasa por 1 - 4, se dará cuenta de que no necesitará Shiro para la autenticación. (: Por lo tanto, estoy recuperando mis palabras, NONCE no se aplica en este caso a menos que esté demasiado preocupado por la seguridad sobre el rendimiento.

¿Por qué me importa el ataque MITM? Mi cliente (código javascript ajax) obtiene datos de su servidor a través de ajax. Así que no creo que deba preocuparme por MITM de ninguna manera.

Creo que debería importarte. MITM Attack significa que sus solicitudes / respuestas están siendo encadenadas a través de una máquina (MITM) a su enrutador. Si se trata de una solicitud sin cifrar, todo es texto sin formato al MITM. Puede ver todas sus solicitudes ... y posiblemente suplantar las solicitudes y puede secuestrar la sesión. Déjame encontrar un ejemplo ... http://michael-coates.blogspot.com/2010/03/man-in-middle-attack-explained.html

No tengo mucha experiencia en los marcos de autenticación de Java y el flujo de trabajo de autenticación en general (solo algunos conocimientos teóricos), por lo que, con fines educativos, estoy tratando de crear este tipo de autenticación para mi aplicación HTTP:

  1. Entradas de cliente login + contraseña a /login .
  2. Shiro inicia sesión en el usuario por las credenciales dadas. El servidor devuelve al cliente su sessionId .
  3. El cliente solicita algún tipo de recurso /myresource?sessionId=1234567 .
  4. Shiro inicia sesión en el asunto por un sessionId dado. Luego, el servidor realiza el flujo de trabajo regular para obtener el /myresource (con Shiro administrando los derechos de acceso a nivel de método).

Básicamente tengo estas preguntas:

  1. Supongo que no necesito sesiones HTTP ni sesiones de Servlet. Shiro tiene su propio administrador de sesión, que es suficiente para mis necesidades. ¿Me equivoco?
  2. ¿Es una buena práctica dar al cliente el sessionId real o debo enviar algún tipo de sessionToken (que se resuelve en sessionId en el lado del servidor)?
  3. ¿Cómo inicio sesión en el Asunto usando sessionId (que el cliente debe almacenar localmente)?
  4. ¿Hay alguna otra cosa que deba saber antes de realizar este tipo de autenticación?

Gracias por adelantado.