Prerrequisitos

Software: 

 Se presupone instalado y funcionando el Middleware WSO2 API Manager.

Implementación

 Para que el código quede más visual, se trabaja con la herramienta wso2 tooling, pero esta no es necesaria, ya que los ficheros son xml.

Ejemplo de Mediación "In Flow"

Ejemplo de Mediación "Out Flow"

Para poder realizar las pruebas funciones es necesario lo siguiente:

 Debemos tener en cuenta que Kong usa servicios y rutas, los servicios son las entidades que agrupan a las rutas, las rutas son endpoints, al contrario que las apis, los servicios no tienen un basepath, este se define en cada ruta. Los servicios sí incluyen plugins, que son los que aportan funcionalidad, además es en los servicios donde se configura el target al que apuntarán el conjunto de rutas que vayamos declarando. Los plugins también pueden ser configurados a nivel de ruta, lo que permite una mayor customización de cada endpoint.

Pruebas técnicas, Seguridad:

Se ha probado la protección mediante api keys, no presenta ningún problema se usa para ello el plugin del mismo nombre. 

Respecto al oauth2, Kong soporta los distintos tipos a través de otro plugin, pero la implementación en el caso de el grant_type password, es diferente a la que realizamos en apigee.

En kong el cliente llama a un microservicio, que hace la validación de las credenciales, si son correctas, el microservicio llama a kong que será el que genere el token y lo administre de ahora en adelante (esta última parte sí es similar), realizando las validaciones de token para los recursos protegidos.

Esta arquitectura no presenta ningún problema,  de utilizarse, sólo habría que tener en cuenta que el microservicio que haga el chequeo de credenciales, se tendrá que colocar delante de kong, y no detrás como teníamos pensado en apigee. 

En el resumen de funcionalidades podemos encontrar lo siguiente: