sirve responsebody requestbody que por para mvc example con basada autenticacion ajax spring rest spring-security restful-authentication

responsebody - Cómo diseñar el sistema de autenticación y autorización para la aplicación de servidor de fondo REST/Ajax frontend



jquery ajax json spring mvc example (3)

Como entendí que va a asegurar una aplicación de descanso, para comenzar debe saber que un proveedor de seguridad consta de tres conceptos (3A): -Autentización -Autorización -Auditación

para implementar estos tres juntos, debe proporcionar un montón de herramientas, tales como: -SSO Provider -Session Store -Open Id patrón-integración de credenciales de usuario ...

He utilizado ACL (Spring ACL) para proporcionar servicios de autorización y oauth2 para la autenticación. hay un canal para conectar estos dos juntos y sus ámbitos (oauth2), pero el problema es que los ámbitos no son lo suficientemente flexibles (cadenas puras) para implementar módulos de autorización como role_voter, cache_strategy, black_list o, Role_base, permisos excepcionales, white_list. .. (pero puede usar @EnableGlobalMethodSecurity)

En mi caso, utilicé el servidor de autorización como recurso para el servidor de autenticación auth2 (consulte http://projects.spring.io/spring-security-oauth/docs/oauth2.html ), luego consideré dos lugares para verificar la autorización , el primero que emití ACL al programador frontal y forzado a diseñar su página dinámicamente según el concepto de ACL, el segundo está en back-end en la capa de servicio (BLL) usando Aspect cuando se va a llamar a un puesto de descanso. Envié la clave de servicio como un actee para verificar si el usuario actual tiene suficiente control de acceso para hacerlo. y para la auditoría, debe monitorear todas las solicitudes. Quiero decir que debe usar un oyente en su puerta de enlace o corredor ...

Estoy empezando un nuevo proyecto en el que estamos planeando construir un back-end tranquilo y un extremo de fuente AJAX. Me estoy acercando al problema enfocándome en Identificar todos los recursos que tengo y lo que los diferentes verbos HTTP los harán, su URI y las representaciones JSON de esos recursos.

Estoy buscando el mejor diseño para asegurar el backend. Aquí está la lista de diseños que he considerado. Estoy buscando diseños alternativos que no se enumeran a continuación, y pros, contras recomendaciones. El sistema se implementará con Spring 3.0 y posiblemente con Spring Security 3.0, SSL se usará para muchas partes del sistema pero no para todas, por lo que algunas solicitudes pueden provenir de SSL y otras no.

Opción 1: usar la sesión HTTP

Muestre una pantalla de inicio de sesión estándar, cree una sesión del lado del servidor y deje que Tomcat devuelva una cookie jsessionid y haga que el cliente ajax incluya la cookie JSESSIONID en cada solicitud XHR. Estas opciones simplemente se sienten como si se tratara de un enfoque incorrecto por las siguientes razones.

  • La conexión se convierte en un estado que está en contra de las reglas de REST.
  • Quiero poder dividir el bakcend en varios archivos WAR separados, lo que significa que podría tener varias sesiones HTTP en el backend, si ese es el caso, este enfoque no funciona. Si bien no necesito la capacidad de dividir el backend en varias aplicaciones hoy, preferiría un diseño que permita esa posibilidad.

Opción 2: encontrar una biblioteca de seguridad basada en Java de código abierto que haga esto

Aparte de la seguridad de Spring, no he encontrado ninguna otra biblioteca de Java, cualquier recomendación es muy apreciada.

Opción 3: intente utilizar un protocolo existente como OAuth

En mi breve vistazo a OAuth, parece que está diseñado para la autenticación en sitios donde cada sitio tiene su propia base de datos de usuarios. En este sistema, quiero una base de datos global de usuarios compartida en todos los servicios back-end ajax.

Opción 4: usar SAML y Shiboleth

Estas opciones parecen ser excesivamente complejas y enormemente complejas de configurar y mantener.

Opción 5: Enviar el nombre de usuario y contraseña con cada solicitud

Esto requiere que el usuario envíe su nombre de usuario y contraseña con cada solicitud, lo que significa que la aplicación AJAX debe almacenar el nombre de usuario y la contraseña como un objeto de JavaScript y si el usuario navega fuera de la página, entonces el combo de contraseña / nombre de usuario desaparecerá. y el usuario podría verse obligado a iniciar sesión de nuevo. No quiero que el front-end intente poner el nombre de usuario y la contraseña en una cookie, ya que eso incluiría seguridad.

Opción 6: implementar mi propio protocolo de autenticación / autorización

Cree un servicio REST en el que los usuarios puedan presentar su combinación de nombre de usuario / contraseña y luego recuperar y el token de seguridad, que deben enviar al servicio con cada solicitud. El token de seguridad estaría firmado digitalmente por el servicio y tendría un tiempo de caducidad. El token solo sería bueno para la mayoría de las operaciones. Las operaciones de alta seguridad requerirían una nueva pantalla de inicio de sesión como puerto para confirmar la operación.

El problema con este enfoque es que tengo que inventar otro protocolo de seguridad que parece una pérdida total de tiempo.

Estoy seguro de que no soy la única persona que se enfrenta a este problema, espero que la comunidad de desbordamiento de pila pueda señalar algunas opciones y herramientas que aún no he encontrado.

Echa un vistazo a Apache Shiro . Es un sistema de autenticación que tiene una función de administración de sesión que se puede usar para compartir sesiones entre aplicaciones. Esto puede ser lo más fácil de hacer.

O puede usar Spring Security (o Shiro) con una cookie Remember Me que se comparte en las aplicaciones web (siempre que estén en el mismo dominio HTTP). La cookie "Recuérdame" sería análoga a tu token en la opción 6. Puedes establecer la caducidad de la cookie de modo que sea de corta duración como una cookie de sesión o de larga duración como un recordado regular.

Es posible que también desee echar un vistazo a Jasig CAS - Inicio de sesión único para la Web. Cuenta con una API REST y un protocolo (Proxy Tickets) que permite que los servicios apoderen al usuario AuthN para respaldar servicios como usted describe en la opción 6. http://www.jasig.org/cas

Brevemente ... la aplicación que sirve al cliente AJAX está protegida con Spring Security (es compatible con CAS fuera de la caja) y obtiene un ticket de concesión de proxy que se incrusta en el cliente AJAX. El cliente AJAX usa el PGT para obtener tickets Proxy para sus servicios REST ... protegidos también con Spring Security. Los servicios REST obtienen un ID de usuario autenticado sin que se toquen las credenciales principales.

Como alternativa, puede mantener el PGT en el servidor y usar las llamadas AJAX para recuperar boletos Proxy que luego son utilizados por el cliente AJAX para llamarle a los servicios REST.