Aplique control de acceso y enrutamiento de grano fino con API Connectivity Manager

Una parte importante de la gestión de las API a lo largo de su ciclo de vida es el control detallado del acceso a las API y el enrutamiento del tráfico. Los tokens de acceso han surgido como el estándar de facto para gestionar el acceso a las API. Una de las ventajas de los esquemas de autenticación basados en JSON Web Tokens (JWT) es poder aprovechar las afirmaciones en el JWT para implementar ese alto nivel de control de acceso. Los permisos se pueden codificar como reclamos personalizados, que los propietarios de API pueden usar para controlar el acceso a sus API. Una vez que el proxy API ha validado el JWT, tiene acceso a todos los campos del token como variables y puede basar decisiones de acceso en ellos.

En una publicación anterior , analizamos cómo API Connectivity Manager puede ayudar a los operadores y desarrolladores a trabajar mejor juntos. Los equipos de diferentes líneas de negocio que poseen y operan API necesitan control total a medida que desarrollan y mejoran la experiencia de sus API y servicios.

API Connectivity Manager proporciona políticas que permiten a los propietarios de API configurar ajustes a nivel de servicio, como autenticación de API, autorización y requisitos de seguridad adicionales. En esta publicación, mostramos cómo los propietarios de API pueden usar la política de enrutamiento de control de acceso para aplicar un control detallado para rutas específicas y ajustarlo aún más para que se aplique por método HTTP y por ruta en función de reclamos específicos en el token.

Requisitos previos

Debe tener una suscripción de prueba o paga de F5 NGINX Management Suite , que incluye Instance Manager y API Connectivity Manager junto con NGINX Plus como puerta de enlace de API y NGINX App Protect para proteger sus API. Para comenzar, solicite una prueba gratuita de 30 días de NGINX Management Suite .

Para obtener instrucciones sobre cómo instalar NGINX Management Suite y API Connectivity Manager, consulte la Guía de instalación .

Conceder acceso y enrutar el tráfico a un servicio específico

Digamos que hemos publicado un proxy de API de almacén con varios puntos finales, como inventario , pedidos , etc. Ahora queremos presentar un nuevo servicio llamado precios , pero hacerlo accesible sólo para unos pocos clientes que se hayan registrado para una prueba beta. Estos clientes se identifican mediante un reclamo llamado betatester . En este token de acceso de muestra, esa afirmación es verdadera para el usuario identificado en la afirmación secundaria , user1@abc.com .

Encabezado
{
"niño": "123WoAbc4xxxX-o8LiartvSA9zzzzzLIiAbcdzYx",
"alg": "RS256"
}
Carga útil

{
"ver": 1,
"jti": "AT.xxxxxxxxxxxx",
"iss": "https://oauthserver/oauth2/",
"aud": "inventoryAPI",
"iat": 1670290877,
"exp": 1670294477,
"cid": "AcvfDzzzzzzzzz",
"uid": "aaaaaaaWPXulqE4x6",
"scp": [
"apigw"
],
"auth_time": 1670286138,
"sub": "usuario1@abc.com",
"betatester": verdadero,
"dominio": "abc"
}

Para user2@abc.com , que no fue elegido para el programa beta, el reclamo del betatester se establece en
FALSO:

"sub": "usuario2@abc.com","betatester": falso,

Ahora configuramos la política de enrutamiento de control de acceso ( access-control-routing ) para otorgar acceso al servicio de precios a los usuarios cuyo JWT contiene el reclamo betatester con el valor true .

Para abreviar, mostramos solo la carga útil de la política. Esta política solo funciona con políticas basadas en tokens en API Connectivity Manager, como JWT Assertion y OAuth2 Introspection.

"políticas": { "enrutamiento de control de acceso": [
{
"acción": {
"condiciones": [
{
"permitirAcceso": {
"uri": "/precios"
},
"cuándo": [
{
"clave": "token.betatester",
"matchOneOf": {
"valores": [
"verdadero"
]
}
}
]
}
],
"códigoDeRetorno": 403
}
}
]
}

Una vez que aplicamos la política, el proxy API valida las reclamaciones en el JWT para los usuarios autenticados, realizando un control de acceso detallado para enrutar las solicitudes de user1@abc.com y rechazar las solicitudes de user2@abc.com .

Control del uso de métodos específicos

Podemos ajustar aún más la política de enrutamiento de control de acceso para controlar qué usuarios pueden usar métodos HTTP específicos. En este ejemplo, el proxy API permite que solo los administradores (usuarios cuyo token incluye el valor Admin ) utilicen el método DELETE .

"políticas":{ "enrutamiento de control de acceso":[
"acción":{
"condiciones":[
{
"cuándo":[
{
"clave": "token.{reclamos}",
"coincidencia con uno":{
"valores":[
"Administrador"
]
}
}
],
"permitir acceso":{
"uri": "/v1/cliente",
"métodoshttp":[
"eliminar"
]
},
"ruta a": {
"etiqueta_de_retorno_destino": ""
}
}
]
}
]
}

Enrutamiento basado en encabezados

Otro uso de la política de enrutamiento de control de acceso es tomar decisiones de enrutamiento basadas en los valores de encabezado de las solicitudes entrantes. Los propietarios de API pueden configurar reglas o condiciones que especifiquen los valores en el encabezado que deben coincidir para que se enrute la solicitud. Las solicitudes se reenvían si contienen el encabezado y se descartan si no lo contienen.

En este ejemplo, una solicitud se enruta al punto final /seasons solo cuando el encabezado de solicitud de versión tiene el valor v1 . El valor returnCode especifica el código de error que se devolverá cuando la versión no sea v1 ; en este caso, es403 (Prohibido) .

"access-control-routing": [ {
"action": {
"conditions": [
{
"allowAccess": {
"uri": "/seasons"
},
"when": [
{
"key": "header.version",
"matchOneOf": {
"values": [
"v1"
]
}
}
]
}
],
"returnCode": 403
}
}
]

En este ejemplo de solicitud curl , enviamos una solicitud al servicio seasons con el encabezado de versión establecido en v2 :

curl -H "versión: v2" http://ejemplo.com/temporadas

Debido a que el valor del encabezado de la versión no es v1 como lo requiere la política, el servicio devuelve el código de estado403 .

Inclusión de múltiples reglas en la política

Puede incluir varias reglas en una política de enrutamiento de control de acceso para controlar el enrutamiento según uno, dos o los tres criterios analizados en esta publicación: Reclamaciones JWT, métodos válidos y valores de encabezado de solicitud. Una solicitud debe cumplir las condiciones de todas las reglas para ser enrutada; de lo contrario, se bloquea.

resumen

API Connectivity Manager permite a los propietarios de API controlar y mejorar la experiencia de sus API y servicios con políticas a nivel de API que aplican un control de acceso detallado y toman decisiones de enrutamiento dinámicas.

Para comenzar a utilizar API Connectivity Manager, solicite una prueba gratuita de 30 días de NGINX Management Suite .