En una entrada de hace poco más de un año había mostrado cómo trabajar con la seguridad a nivel de UserNameToken, usando el WSO2 Application Server e implementado el cliente con Axis2. En ese momento no compartí el código y es generó varias preguntas enviadas a mi buzón de correo y por el propio post.
Ahora volviendo al mismo tema y apoyándome en una excelente entrada de Roger Carhuatocto veremos un poco más en detalle el código empleado.
Al revisar el código una de las primeras cosas que podemos notar son las líneas encargadas de establecer una conexión HTTPS usando un almacén de llaves del tipo JKS. En este caso en particular usamos el mismo del WSO2 AS que tiene como contraseña wso2carbon.
Otro segmento de código importante es el que usamos para acceder a las opciones del stub para poder engancharle el módulo de rampart, encargado de la seguridad en axis2. También con el stub podemos, usando las opciones, setear el usuario y la contraseña y por último cargar en una propiedad la política de seguridad que tenemos almacenada en un fichero con formato XML.
A partir de este segmento de código la implementación es la misma que si el servicio fuera inseguro. Y ahora apoyandonos en el post de Roger explicaremos el por qué de estos ajustes.
Roger nos comentaba en su entrada que en la política de seguridad definida por defecto para el escenario UserNameToken se especifica que:
- Se requiere HTTPS en vez de HTTP. Este último ya no está disponible cuando le asignamos la seguridad al servicio.Esto implica que el canal de seguridad está encriptado razón por la cual debemos especificar el almacén de certificados para la conexión SSL.
- Se debe enviar las credenciales de autenticación del usuario, usuario y contraseña, en el mensaje que viaja por el canal encriptado. De ahí que debamos especificar en las opciones del stub el usuario y la contraseña.
- El UserNameToken debe ir firmado, para evitar que se alteren los datos de autenticación.
Y para lograr especificar todo esto es que se crea una política de seguridad que es cargada como una propiedad más en el stub.
Sin más les dejo el enlace a los repositorios en github donde he puesto el código de:
- Proyecto que genera el aar del servicio a desplegar en el WSO2 AS.
- Proyecto que contiene la implementación del cliente seguro que consume el servicio del punto anterior, una vez asegurado con UserNameToken.
Para generar el aar deben ejecutar el comando: mvn clean package en el primer proyecto.
En el caso del segundo proyecto basta con el comando: mvn clean compile para que compilen las dos clases, el stub, y el cliente y puedan ejecutar el main de ejemplo.
Quedamos al tanto de cualquier situación que se les presente y espero que puedan consumir servicios seguros sin problema.
Entradas
WSO2 y la seguridad UserNameToken.Recapitulando.