OTN Appreciation Day: OWSM y WS-Security. Autenticación por Username Token para SOAP y REST en OSB 12c.

Hola!

Este post es especial y está enfocado a expresar de alguna manera nuestro agradecimiento a OTN por el arduo trabajo de difusión en la comunidad de Oracle a nivel global. La idea, salida de la imaginación de Tim Hall (un personaje ampliamente reconocido en el ámbito de bases de datos y que recientemente nos acompañó en el OTN Tour Latinoamerica 2016), es crear un artículo mencionando alguna característica que nos agrade de las herramientas y tecnologías con las que trabajamos constantemente y así continuar con esta labor de colaboración. Por mi parte, mencionaré un ejemplo para usar policies de autenticación para los servicios web en OSB 12.2.1,  misma que representa una característica que me ha gustado bastante ultimamente, espero les sea de utilidad.

WS-Security es una especificación publicada por OASIS, está dirigida a Servicios Web de tipo SOAP, y en ella se contempla una serie de mecanismos para reforzar la integridad y confidencialidad de los mensajes que se intercambian entre estos servicios, tal es el caso de la encripción de datos, tokens de seguridad, validación de usuario y password, mensajes firmados, etc.

Por otro lado, Oracle Web Service Manager (OWSM) es un componente de la Suite de SOA de Oracle que provee un framework de centralización de políticas de administración y seguridad de los Servicios Web. OWSM está basado en el estándar WS-Policy y puede ser usado en tiempo de desarrollo, o bien, desde la consola de administración. 

En OWSM intervienen los siguientes elementos principales:

• Policy Manager: Lee y escribe las políticas, ya sean predefinidas o personalizadas, de y hacia el repositorio.
• Agent: Ejecuta las políticas y recopila estadísticas de ejecución. Mantiene un caché de memoria para las políticas. Se compone de un Policy Access Point (PAP)  y un Policy Interceptor, el primero se comunica con el Policy Manager usando invocaciones EJB, mientras que el segundo se genera cuando un Servicio Web se despliega y se activa, o cuando se relaciona una política a un Servicio Web, y su función es interceptar las peticiones hacia el Servicio Web y ejecutar las políticas asociadas a éste.
• OWSM Repository: Lugar donde se almacenan las políticas, típicamente es una base de datos.
• Enterprise Manager: Aplicación, donde además de la gestión de diversos elementos, se lleva a cabo la configuración de OWSM, métricas, etc.

En este artículo encontrarás la forma de configurar, en tiempo de desarrollo, una política de autenticación basada en usuario y password para un Servicio Web SOAP y uno de tipo REST, usando OWSM y OSB 12.2.1, basado en la especificación WS-Security. El usuario y password viajarán embebidos en el elemento UsernameToken dentro del Header del mensaje SOAP Envelope y para el caso del servicio REST, viajará en el Header de transporte HTTP. Además, podrás ver la forma de probarlo usando SOAPUI y POSTMAN.

El primer paso es construir y desplegar un servicio Proxy SOAP en OSB, en este ejemplo no lo vamos a desarrollar, puesto que no es el foco del artículo, en lugar de eso usaremos uno ya existente llamado PersonaSOAP.proxy. Al acceder al url del WSDL podemos ver la definición del servicio, el cual tiene una sola operación y un header de request y uno de response.

Debido a que es un mock, siempre regresará una respuesta exitosa, para fines de esta prueba. Al ejecutar el servicio en SOAPUI vemos el mensaje de request y de response.

Para comenzar a asignar la política de seguridad, en JDeveloper editar el servicio proxy, en la pestaña Policies inicialmente no tiene configurada ninguna política.

Seleccionar el radio botón From OWSM Policy Store. Luego, cuando se despliegue la sección inferior, clic en el símbolo azul + en la parte correspondiente a Security.

Seleccionar oracle/wss_username_token_service_policy de la lista de políticas predefinidas. OK para continuar.

Así es como debe quedar la configuración.

Guardar y redesplegar el proyecto en OSB. Una vez desplegado, volver a verificar el url del WSDL, esta vez notarás que se agregaron algunas definiciones de la política de seguridad.

Para poder ejecutar el servicio, es necesario asegurarte de tener instalado y en ejecución el OWSM. Puedes verificarlo en la consola de administración del Weblogic, en la sección Environment, Servers. Aquí se despliega la lista de servidores del dominio, asegúrate que él o los nodos del WSM estén en ejecución, de lo contrario no podrás realizar la configuración de la política.

Una vez que estés listo para probar el servicio, lo puedes hacer con el cliente que desees, en este caso usaremos SOAPUI, y para llevarlo a cabo es necesario configurar las opciones para agregar el header donde estará el token de usuario y password. En la sección inferior del request, clic en Auth y seleccionar Add New Authorization del combo.

Seleccionar Basic y clic en OK.

Introducir las credenciales de un usuario válido y previamente creado en Weblogic.

Si probamos el servicio en este punto, el resultado será un error de autorización, debido a que no hemos agregado el encabezado con el token de usuario y password.

Para agregar el token a la petición, clic derecho en el mensaje de request, Add WSS Username Token.

Seleccionar PasswordText y clic en Aceptar.

Se agregará el encabezado Security dentro del elemento Header del mensaje Envelope.

Si volvemos a ejecutar el servicio, la autenticación se realizará y el mensaje podrá llegar a su destino en el OSB.

Así de sencillo concluye la configuración de la política de autenticación en el mensaje SOAP. Si deseas que el usuario y password no viajen en el elemento Header del Envelope, pero sí en el Header del transporte HTTP, puedes usar la política wss_http_token_service_policy. 

 

Por ejemplo, en el caso de un Proxy de tipo REST, donde no existe el mensaje Envelope, puedes configurar esta política para enviar peticiones con usuario y password en el Header HTTP. La configuración queda como se muestra a continuación:

Después de desplegar el servicio, puedes probarlo con el cliente REST que prefieras, en este ejemplo usaremos POTSMAN. La petición sin headers de autorización regresa un error:

Para agregar los headers ir a la pestaña Authorization y seleccionar Basic Auth.

Introducir usuario y password y clic en Update Request.

Notarás que en la pestaña Headers se agregó un elemento Authorization con un valor encriptado.

Al enviar una nueva petición, verás que la política de seguridad se ha aplicado correctamente y la respuesta es exitosa.

Ahora ya sabes cómo agregar validación de usuario y password en ambos tipos de servicios, SOAP y REST publicados en OSB, usando las políticas por defecto del OWSM.

Nos leemos pronto!