Mostrando entradas con la etiqueta ws-policy. Mostrar todas las entradas
Mostrando entradas con la etiqueta ws-policy. Mostrar todas las entradas

jueves, 5 de enero de 2017

Axis2: Seguridad en WSO2 AS 5.3.0

image

Ayer revisando StackOverflow me he topado con una pregunta sobre como establecer la seguridad para un servicio axis2 desplegado en el WSO2 AS 5.3.0 y la verdad es que desconocía que esta funcionalidad, muy buena por cierto, había sido removida de la interfaz web.
Realmente no me ha gustado que se removiera, pues de una manera muy fácil permitía a los desarrolladores definir la seguridad para los servicios axis2, pero son cosas de la compañía WSO2 que habría que revisar los pro y los contras.

La respuesta a la pregunta está en el enlace que puse más arriba pero lleva un trabajo adicional a lo que se hacía antes a través de la UI. Se necesita:
  • Identificar el XML que define la política que queremos usar. En mi respuesta usé la más sencilla, UsernameToken over HTTPs.
  • Incluir en el fichero services.xml del servicio axis2, que está dentro del fichero .aar la referencia al módulo de rampart. Que es el que define la seguridad para el framework axis2.
  • Definir cómo se vinculará la política con las distintas operaciones del servicio y donde será adjuntada.
  • Definir algunas configuraciones propias de rampart dentro de la política para la encriptación y uso de los usuarios del WSO2 AS y también una configuración extra para el carbon definiendo los roles que tendrán permiso de acceso al servicio.
Una vez que se tiene un ejemplo resulta más fácil establecer la seguridad para cualquier servicio axis2 pero para aquellos que no dominan el framework puede llevarle horas o días dar con la configuración correcta. De ahí que me decidiera a compartir un ejemplo sencillo que les sirva a los que se enfrente a este pequeño problema.

jueves, 12 de noviembre de 2015

La seguridad en WSO2 ESB 4.9.0

image

En esta entrada estaré mostrando la manera correcta de hacer seguros los servicios en la suite de WSO2 partiendo del uso de la nueva versión de WSO2 ESB 4.9.0 y del WSO2 Developer Studio 3.8.0.

Como ya se ha explicado las facilidad de asignarle la seguridad a un servicio proxy desde la consola web del WSO2 ESB ha desaparecido y ahora se debe realizar desde el Developer Studio.
Comenzaremos a partir de un servicio proxy sencillo creado en el DVS, como pueden observar en la imagen inicial de esta entrada. Contiene 2 mediadores logs, uno en la sencuencia de entrada y otro en la de salida y un endpoint apuntando a un servicio desplegado en el WSO2 Application Server.

En este enlace  les dejo el proyecto del Synapse y un proyecto que contiene el recurso usado hasta el momento, el WSDL del servicio desplegado en el WSO2 AS, junto con el .aar a desplegar.

A partir de aquí el servicio sin seguridad se encuentra desplegado en el WSO2 ESB y es completamente funcional. Queda agregarle la seguridad. Los pasos son los siguientes:

Paso 1: Crear la política de seguridad.
Crearemos un recurso del registro a partir de un template tal como se muestra en la siguiente imagen.

image

Seleccionen el template de WS-Policy y definan el proyecto de Resources donde van a guardar este nuevo recurso.

image

Una vez que se da clic en Finish se visualiza la siguiente pantalla:

image

Se aprecian los 2 artefactos existentes, el WSDL del servicio backend y la política recién creada a partir del template. Procedemos a abrir esta política dando doble clic en el fichero generado en el proyecto.


image

Verán que se abre una ventana para seleccionar la política de seguridad a aplicar, en nuestro caso es la de UserNameToken.

image

De manera curiosa pueden dar clic en User Roles y si tienen el WSO2 ESB Online cargar los roles existentes y seleccionar aquellos roles a los que le quieran dar acceso a este servicio.

image

Una vez realizado esta selección ya la política está creada y lista para ser usada.


Paso 2: Asignar la política de seguridad al servicio.
Este paso es muy simple. Debemos ir a las propiedades del servicio proxy y marcar como “true” la que indica en la sección de Security, la propiedad Security Enabled como se muestra en la imagen más abajo.

image

Luego en la misma sección vamos a Service Policies y buscamos en el proyecto del registro la política recién creada.

image
OJO: a la hora de realizar el despliegue tengan presente que en el proyecto deben marcar que esta nueva política se despliegue en el ESB, no en el GREG como se crea por defecto.

Una vez desplegado el servicio SecurityTest lo veremos en el DashBoard:

image


Paso 3: Pruebas.

Podemos probar el servicio usando la funcionalidad del TryIt.

image

Y también usando el SOAPUI:

image
En este caso al no especificar el header de seguridad(timestamp + user/name token) la invocación falla.

Procedemos a incluir el header de seguridad en el SOAPUI:

image


Y al invocar al servicio obtenemos una respuesta exitosa.

image

Les dejo a continuación un adjunto con los proyectos actualizados.

Espero les sea de utilidad.