lunes, 3 de marzo de 2014

WSO2 y el filtrado de las acciones en los servicios.

Hace poco en un curso que estaba dando sobre el ESB de WSO2 le comentaba a los estudiantes que se presentan ocasiones en que el servicio backend que queremos exponer a través de un servicio proxy tiene más operaciones que las que deseamos sean expuestas, y que hay varias formas de implementar para evitar que las mismas sean accedidas desde el servicio proxy.

Una variante sencilla es no exponer estas operaciones vía el WSDL del servicio proxy, de esta manera quienes estén creando un cliente del servicio proxy no verán las operaciones.

Otra variante puede ser una autorización a nivel de operaciones, aunque en este caso me queda la duda de si se puede lograr fácilmente pues las políticas de seguridad en el ESB se adjuntan al binding y no a las operaciones.

Otra variante es implementar un mecanismo de autorización de grano fino, donde por intermedio del mediador Entitlement podamos consultar políticas de seguridad definidas en el Identity Server de WSO2 y de esta manera determinar qué usuarios y/o roles y bajo cuales circunstancias tienen acceso a determinadas operaciones. Creo que es la solución más fuerte.

Otra variante si no quieren complicarse mucho es ir al dashboard del servicio y en la sección de “Quality of Service Configuration” pinchar donde dice “Operations


Seleccionar la operación a la cual desean denegar el acceso:

Y verán un dashboard solo para esta operación.


Ahí deben pinchar donde dice “Access Throttling” y llegaran a una pantalla como esta.

Si lo ponen tal y como se les muestra será imposible consumir esta operación. En la consola de la herramienta saldrá algo como lo siguiente:


Si tratan de consumir la operación desde un cliente, en mi caso uso el SOAPUI, verán lo siguiente:




Evidentemente estamos prohibiendo el acceso desde cualquier IP a esta operación. Si prueban las otras funcionarán sin problemas.

La mejor variante será la que mejor se adapte a sus requerimientos e igual se puede dar el caso en que haya que combinar 2 o más variantes.

Lo que no me ha gustado de esta configuración de filtrado, es que si el filtrado propuesto lo hacemos en un servicio backend  y luego creamos un proxy de este servicio, cuando invocamos a la operación no obtenemos nada como respuesta, o sea el mensaje de fallo no se propaga como corresponde. En mi caso estoy usando un ESB con las features del AS embebidas, pero no creo que ese sea el problema. He movido este bloqueo para el servicio proxy y con los mismos resultados. Solo en pocas ocasiones me ha devuelto un mensaje de fallo, pero nunca ha pasado por la secuencia de fallo que le definí.

Ilustrando este problema:
Imagen de cuando si retorna un mensaje fault el servicio proxy:


En la siguiente llamada falla y es un comportamiento aleatorio:



0 comentarios:

Publicar un comentario