Securizando APIs en CAP sin XSUAA (Enterprise Business HUB)

Com ya conocéis, podemos añadir un binding des de nuestro servicio CAPm a un servicio XSUAA para hacer seguras nuestras APIS.

Pero que ¿pasa si lo que queremos es utilizar «usuarios técnicos» y a demás queremos proporcionar credenciales distintas en función del consumidor de estas APIS?

La solución podría ser crear usuarios tipo técnico en para nuestro cloud, pero en este caso la contraseña de estos usuarios tiene caducidad así que no seria una muy buena opción.

La opción mas viable es utilizar el servicio de API Management para añadir una API key en nuestra API. Pero esta solución nos plantea un problema adicional, ¿qué hacemos con la URL que nos genera nuestra cuenta cloud? Como sabéis esta URL estaría sin protección así que en esta entrada veremos como securizar nuestra API.

Si… esta vez la introducción es un poco rara, ya que este es un problema concreto de cuando queremos crear APIS para que una aplicación externa las utilize con usuarios técnicos.

Un ejemplo practico del problema

Para verlo más claro, vamos a publicar nuestra API generada con el template de BAS y sin modificarla. La única cosa extra que le añadiremos es un cambio de la URL por defecto:

Con este cambio he conseguido que mi URL de servicio sea la siguiente: https://ecastella-myapi.cfapps.us10.hana.ondemand.com

Si accedemos a la API, sin usuario, podemos acceder a los datos:

Lo que queremos es evitar que alguien pueda acceder a los datos sin una clave. Si añadimos en la configuración del servicio la restricción de usuario técnico lo conseguiríamos, pero el problema es que a todos nuestros proveedores les tendríamos que facilitar las mismas credenciales, así que en caso de una brecha de seguridad no tendríamos margen.

API Business HUB al rescate

Para solucionar este problema, vamos a crear una nueva API en el API Management, crearemos un productivo en API Hub y añadiremos una redirección de la ruta de nuestro servicio.

Antes de seguir, un aviso, esta solución es eficiente para fines formativos, en el entorno productivo añadiríamos un JWT que descodificaríamos también con políticas en API Management.

Si quieres saber mas sobre API management te recomiendo esta entrada:

Nuestras APIS publicadas en SAP Cloud API Management en 5 minutos

Dando de alta nuestra api en API Management

En este ejemplo damos por hecho que ya tenemos la API desplegada así que es momento de ir a nuestro servicio de API Management y dar de alta la API.

• Crearemos una entrada en API provider con la URL de nuestra API:

Damos de alta la API en el API management:

Añadimos la configuración

Ya tenemos las configuración apunto, este es el resultado:

Pero seguimos sin ningún tipo de seguridad, esto es lo que pasa si accedemos a la URL que nos ha proporcionado nuestro API Management:

De momento ya nos va bien así, luego jugaremos con las políticas de la API para evitar accesos indeseados. Así que vamos a crear el producto para poder añadir la API en nuestra aplicación de servicio API Business HUB.

Añadiendo la API en SAP API Business HUB

Para acceder al portal, si es es la primera vez, tenemos un acceso directo en nuestro API Management:

Accedemos a la parte de Management para añadir una nueva aplicación:

Creamos la nueva aplicación:

Con esto tendremos la API Key que guardaremos para el siguiente paso:

Restringiendo el acceso al API Management

Ahora vamos a restringir el acceso para que solo se pueda llamar a la API con la API Key. Para esto, vamos a añadir una política en nuestra API.

En la política de la API añadiremos la verificación de la API Key:

Le añadimos un nombre:

Ahora seleccionaremos la nueva política que hemos creado y le añadiremos la validación de la API Key que nos ha proporcionado el servicio de API HUB, a demás indicaremos que estas credenciales estarán añadidas en la cabecera de la petición, si no son validas, no se podrá acceder:

Acordaros de pulsar el botón de Update, guardar los cambios en la API y volver a hacer deploy, este sera el resultado:

Ya tenemos nuestro acceso por API Seguro, pero si alguien tiene nuestra URL de servició puede acceder sin restricciones:

Redirigiendo nuestro servicio

Vamos a a por la última fase. Lo que haremos es que la URL de nuestro servicio redirija al usuario o aplicación hacia el API management para aplicar las políticas y a si no tener una puerta trasera.

Lo primero sera crear una instancia que actuara como AppRouter hacia nuestro tenand de integration suite, para ello, vamos al Market place y creamos una instancia del servicio «apim-as-route-service»:

Este es el resultado:

Ahora iremos al cliente de cloud foundry (podemos usar nuestro BAS) y ejecutaremos este comando:

cf bind-route-service cfapps.us10.hana.ondemand.com apim-router --hostname ecastella-myapi -c "{\"api_name\" : \"myAPI\"}"

Donde los parámetros serán:

• El primer parámetro será el host de nuestra cuenta foundry «cfapps.us10.hana.ondemand.com»
• El segundo es el nombre de la instancia que hemos creado «apim-router»
• El tercer parámetro es el Host que hemos indicado en el archivo MTAR «ecastella-myapi»
• Por último añadimos el nombre del API management que hemos creado en los pasos anteriores «myAPI»

Este es el resultado por consola:

Si ahora accedemos a la URL de nuestro servicio veremos que la API es segura:

Si verificamos el acceso con API Business HUB vemos que si añadimos el APIKey si que podemos acceder a los datos.

---

Como veis es fácil mediante unos pocos pasos añadir seguridad adicional en nuestras APIs cuando estas tendrán que están compartidas con aplicaciones de terceros.

Como siempre suscribete, dale a la campanita de notificaciones y comparte en redes para estar a la última. Vota Like / Dislike para aportar feedback.