JAX-WS, Autenticación y autorización - ¿Cómo?

Question

¿Cuál es la mejor manera de realizar autenticación y autorización en servicios web?

Estoy desarrollando un conjunto de servicios web que requieren control de acceso basado en roles. Usando metro - SOAP, java simple sin EJB.

• que desea autenticar al usuario sólo una vez, usando nombre de usuario y contraseña , que se compara con una base de datos. En las llamadas siguientes.
• Me gustaría utilizar algún tipo de gestión de sesión. Podría ser alguna identificación de sesión , recuperada al cliente al iniciar sesión, para ser presentada en todas las llamadas .

hasta ahora:

• Leer authentication using a database - pero quiero validación de nivel de aplicación;
  

• Lea application authentication with jax-ws - pero no quiero hacer el mecanismo de autenticación todo el tiempo;

• Creo que puedo usar un controlador SOAP para interceptar todos los mensajes y hacer el control de autorización en el hander, usando algún identificador de sesión que viene con el mensaje, que puede coincidir con un identificador guardado en la base de datos, en el método web de inicio de sesión.

EDIT:

todavía tengo algunas preguntas:

• Cómo sabe el nombre del método web que se llama?
• ¿Qué tipo de token debería usar?
• ¿Cómo pasar este token entre llamadas?

EDIT 2

Debido a @ ag112 respuesta:

estoy usando Glassfish.

Uso WS-Policy y WS-Security para encriptar y firmar los mensajes. Usando Autenticación Mutua de Certificado. Me gustaría complementar esta seguridad de nivel de mensaje entre las aplicaciones, con la autenticación y autorización para los usuarios también en el nivel de mensaje.

Solo estoy desarrollando los servicios, y no sé casi nada de los clientes, solo que se podrían crear en diferentes idiomas.

En este punto, creo que lo más importante es hacer lo que tenga que hacer para autenticar y autenticar a los usuarios, la forma más fácil de implementarlo para las aplicaciones cliente.

Answer 1

Después de toda la ayuda, creo que esta respuesta para simplificar y resumir todas las ideas que se discuten.

Las preguntas tiene 2 requisitos: nivel de seguridad

• mensaje;
• Autenticación única.

Con ag112 ayuda, esto es difícil de hacer, o elegante de cualquier manera.Así que aquí están a conclusiones:

• Para la seguridad del nivel de envío de mensajes al usuario credenciales cada vez (lo coloca en la cabecera SOAP);
• Para la autenticación de una sola vez, use la seguridad de nivel de transporte y realice una gestión de sesión .

Prefiero la primera, porque el nivel de mensaje era el mayor requisito.

Answer 2

Como no tenía respuestas, siguiendo @unhillbilly aconsejo, contesto a mi propia pregunta, con el progreso hasta la fecha:

Cómo sabe el nombre del método Web ser llamado;

Usando un controlador SOAP, buscando el nombre del primer elemento en el cuerpo.

Qué tipo de token debería usar;

Decido usar un token de 128 bits, que representa cada sesión. Los servicios web continúan sin sesión, la clave es solo para autorizaciones.

Cómo pasar este token entre llamadas.

Para el método web de inicio de sesión, el resultado tiene el token, en cada una de las llamadas siguientes, el token es un parámetro.

¿hay una mejor respuesta?

Answer 3

También puede optar por OpenEJB.

Usó JAAS con WS-Security.

Espero que el enlace sea útil.

Answer 4

@Luis: Estas son mis entradas.

La solución exacta para su problema depende del tipo de clientes del servicio web que espera, tiene control sobre el sistema cliente del servicio web, su servidor de aplicaciones, etc. ... pero suponiendo que no tiene ningún control sobre la web cliente de servicio, para usted es solo un mensaje SOAP sobre transporte HTTP, aquí hay una solución probable.

Por supuesto, puede realizar la gestión de sesión & autenticación a nivel de mensaje o nivel de transporte. Significa que puede tener token de sesión y información de token de autenticación en el mensaje SOAP o puede usar la sesión HTTP estándar y el mecanismo de autenticación HTTP.

Por supuesto, la solución de nivel de transporte es mucho más simple y estándar en toda la industria en caso de que la capa de transporte sea HTTP. Para el nivel de mensaje, se pueden usar especificaciones ws como ws-security. Su solicitud de cada servicio web es HTTP GET/POST simple identificada por un único URI HTTP. Normalmente en el entorno metropolitano jax-ws, WSServlet es un servlet de entrada para cualquier llamada de servicio web y que finalmente delega la llamada a la clase de implementación del proveedor de servicios adecuado. Dado que su aplicación se implementará en el servidor web, puede explotar todas las funciones de sesión y autenticación proporcionadas por el contenedor web J2ee.

Dado que está buscando el control de acceso basado en roles, usaría el estándar <web-resource-collection> en web.xml para especificar qué función le gustaría tener en caso de un URI HTTP particular. Puede usar el módulo de inicio de sesión JAAS estándar que puede realizar la autenticación y rellena el sujeto JAAS con la función. Si se proporciona el nombre de usuario/contraseña en SOAP XML, el módulo de inicio de sesión JAAS también puede buscar/analizar XML SOAP para recuperar esa información. JAAS/servidor de aplicaciones creará automáticamente el token de autenticación y lo almacenará como una cookie para que cada solicitud posterior no tenga que volver a pasar por el proceso de autenticación. Esto es todo el estándar J2ee. Puede encontrar mucha ayuda en internet sobre esto.Por favor, hágamelo saber su servidor de aplicaciones para que pueda proporcionarle detalles adicionales.

Si aún desea utilizar la gestión de sesión a nivel de mensaje SOAP, proceso de autorización de autenticación &, para proporcionarle más detalles, puedo obtener más información sobre su lado del cliente.

EDIT1: Bueno basa en sus otras entradas, aquí es mis pensamientos más: seguridad Mensaje a saber, el cifrado y la firma tiene que pasar cada mensaje viaja entre el servidor y el cliente. donde, como autenticación de mensaje, tiene la intención de hacer una vez y otorgarle un token de token/auth de sesión al cliente para llamadas posteriores.

La pregunta aún persiste: si coloca un identificador de sesión único en la respuesta SOAP de la autenticación de primera vez, ¿espera que el cliente analice el XML de respuesta SOAP y se asegure de que el cliente le envíe el identificador de sesión cada vez en las solicitudes SOAP subsiguientes. O desea mantener la gestión de sesiones transparente para el cliente y para el cliente necesita enviar nombre de usuario/contraseña de testigo por primera vez y las llamadas posteriores no es necesario requerir alguna señal nombre de usuario/contraseña. En este caso, necesitaría confiar en la gestión de sesión basada en el transporte, por ej. cookies HTTP

Ahora ¿cuál es la mejor para usted depende de su caso de uso. ¿Puede decirme qué es el flujo de casos de uso esperado? cómo otro sistema (cliente del servicio web) realiza más de una llamada de servicio a su sistema? ¿Es otro usuario del sistema impulsado/algún proceso en segundo plano? ¿Cuál es la necesidad exacta de que solo desee que la primera llamada de servicio pase por un proceso de autenticación y no por llamadas posteriores?

PS: servidor Glassfish proporciona una manera de configurar el proveedor de autenticación de mensajes, que activa/desactiva la autenticación de nivel de mensaje de forma automática.

Edit2: entiendo que no desea almacenar las credenciales de usuario en la aplicación cliente y el servidor de servicios web necesitan esas credenciales de usuario. OAuth es un protocolo estándar abierto que permite que el sitio A acceda a los datos privados del usuario en el sitio B. La idea principal es que el sitio A recibe un token de autenticación que tiene un tiempo de caducidad específico. Por lo tanto, el token que contiene cifrado de credenciales de usuario o jsession id lo ayuda a evitar la necesidad de volver a autenticarse. Sólo tiene que decidir dónde quiere mantener símbolo en el lado cliente app Puede mantener token como cookie si el transporte es el protocolo HTTP.

Una vez dicho esto por supuesto pasar credenciales de usuario cada vez que parece poco más fácil y sencillo.