La popularización de arquitecturas centradas en APIs hace que la implementación de productos de gestión de APIs, API Management, sea un elemento cada vez más solicitado, no sólo en nuevos proyectos, sino también como elemento clave para racionalizar y mejorar la seguridad en el acceso a ecosistemas basados en APIs previamente existentes, permitiendo disponer de una plataforma API a nivel empresarial en un producto unificado.
El recurso que ofrece Microsoft para la gestión de APIs es Azure API Management, APIM. Si bien no posee tantas funcionalidades como otros competidores con amplia experiencia en este tipo de productos (Apigee, MuleSoft o API Connect), puede ser una opción ideal en entornos Azure, debido a su perfecta integración con otros recursos en la nube de Microsoft.
Azure APIM está formado por varios componentes:
API Gateway. Es el elemento que gestiona todas las llamadas y las enruta al backend correspondiente. API Gateway permite modificar tanto las llamadas entrantes como las respuestas salientes por medio de policies. Estas se aplican en el Gateway entre el consumidor de la API y la API final. La inclusión de policies nos permite entre otras muchas cosas, transformaciones de datos en caliente, establecer cuotas y límites, cachear respuestas y por supuesto verificar credenciales y certificados. La parte de monitorización y diagnóstico está perfectamente integrada en Azure a través de las herramientas standard, Applicaton Insights, Analytics workspace, etc.
Developer Portal. Portal ofrecido a los desarrolladores de APIs que permite suscribirse a determinadas APIs para ver la documentación asociada, realizar pruebas y acceso a analíticas de uso. Si bien el registro de los usuarios que van a hacer uso de la API es necesario, pueden utilizarse otras herramientas a gusto del desarrollador para las llamadas a API Gateway, curl, soapui, postman, entre otras.
La configuración de ambos elementos se realiza a través del portal de Azure.
El mecanismo de autenticación de caja está basado en la inclusión de una clave en la cabecera de la request, denominada subscription key, asociada a un determinado usuario. API Gateway valida que todas las llamadas tienen una clave válida para el scope de la llamada, rechazando inmediatamente la llamada en caso contrario, sin pasársela al backend.
La principal ventaja de este mecanismo es su sencillez, permitiendo hacer uso de APIM desde el mismo momento que se despliega el recurso, sin embargo, este tipo de autenticación tiene ciertos inconvenientes.
Seguridad. Es el mecanismo de autenticación más débil dado que es sumamente sencillo compartir la clave con terceros. Microsoft recomienda regenerar la clave periódicamente como medida de precaución.
Las distintas subscripciones y claves se gestionan en Azure APIM a nivel de recurso, dificultando la migración del recurso entre diferentes entornos y originando una sobrecarga en la gestión de usuarios.
APIM soporta otros mecanismos para mejorar la seguridad en el acceso a las APIS, incluyendo restricciones de IPs, certificados de cliente y OAuth2.0, siendo esta última la opción preferida debido a su integración entre otros con Azure AAD.
|
La idea es delegar el proceso de autenticación y autorización en el APIM / AAD, descargando a todas las API´s de esta responsabilidad. De este modo APIM se convierte en el punto de acceso a todo el ecosistema de APIs a la vez que agiliza la implementación de nuevas APIs y el mantenimiento de las ya existentes. |
En cuanto a la autenticación, desde el punto de vista de API Gateway, no es necesario ningún tipo de configuración a nivel de APIM, simplemente bastará con añadir las policies necesarias, validate-jwt en este caso. Mediante el uso de esta policy podemos comprobar la existencia y validez del token de acceso, access token, comprobando issuer, audiences y la existencia de determinados claims. También es posible implementar lógica mediante código C# en el caso de que sea necesario procesar el contenido del token o de cualquier otro header para escenarios más complejos.
El manejo de los diferentes scopes en OAuth2.0 permiten limitar el acceso de determinadas identidades a ciertos recursos, bien gestionados en APIM o recursos de terceros, pudiendo establecer así una primera línea de defensa en cuanto a autorización se refiere a nivel de registro de aplicaciones si estamos utilizando AAD como proveedor OAuth2.0.
Una segunda línea de defensa puede implementarse a través de los roles de aplicación en AAD. Esta opción habilita el uso de usuarios y grupos de AAD para segmentar el acceso a las distintas APIs, gestionando la membresía directamente mediante Azure AAD. Dado que es posible incluir este mapeo en el token de acceso, podremos comprobar si un usuario pertenece al grupo requerido al recibir la petición en API Gateway mediante la policy validate-jwt previamente comentada.
APIM es capaz también de realizar llamadas a servicio de terceros mediante la policy send-request, permitiendo obtener información adicional en caso de ser necesaria para la API final. En el siguiente escenario APIM invoca a Microsoft Graph en nombre del usuario para obtener datos adicionales del mismo, y finalmente incluye los datos necesarios en la llamada al backend.
La gestión de usuarios del Developer Portal también puede integrarse con OAuth2.0. en este caso será necesario realizar una serie de configuraciones en el Portal.
Identities. Es necesario añadir un proveedor de identidad, identity provider, que gestione los métodos de autenticación de los usuarios del portal. Tanto AAD como AAD B2C están disponibles. Para el caso de AAD será necesario un registro de aplicación asociado al portal con los permisos necesarios. Una vez configurado, podrá utilizarse el usuario de AAD tanto para registrarse como para logearse en el portal.
Usuarios: Desde el portal de Azure podemos gestionar tanto las cuentas de usuarios locales como las basadas en usuarios de AAD. Las cuentas asociadas a AAD podrán migrarse fácilmente de entorno a entorno vía scripting, ya que no hay ningún secreto asociado a dichos usuarios, en oposición a los usuarios locales que necesitan indicar explícitamente un password en el momento de la creación.
Grupos: Al añadir un proveedor de identidad, a parte de los mecanismos de autenticación a través de AAD, también se habilitan mecanismos de autorización mediante la opción de utilizar los grupos de AAD, por lo que podremos también gestionar a qué Productos / APIs tiene acceso un programador mediante dichos grupos.
Así podríamos crear nuestros propios grupos (mapeo 1-1 con grupos de AAD) y usarlos en la configuración del control de acceso a Productos / APIs en lugar de los grupos predefinidos. Una vez establecida la configuración propuesta, no sería necesario el uso de subscriptions keys, garantizando así el proceso de autorización en base a los grupos de AAD.
Si bien APIM ofrece de caja un mecanismo de seguridad básica basada en subscription keys, es sumamente recomendable explorar las capacidades de integración con OAauth2.0 que ofrece. Debido a la creciente popularidad de Office365 / Azure AAD, basar los mecanismos de autenticación y autorización en Azure AAD se presenta como la mejor opción en la mayoría de los casos.
ifgeekthen.nttdata.com es un blog del grupo NTT DATA. Un proyecto que busca compartir con profesionales del mundo digital temas relacionados con la tecnología y el universo geek.
