Aplique un control de acceso granular y enrutamiento con API Connectivity Manager

Veena Raja Rathna

Una parte importante de la gestión de las API a lo largo de su ciclo de vida es el control pormenorizado del acceso a las API y del enrutamiento del tráfico. Los tokens de acceso se han convertido en el estándar de facto para gestionar el acceso a las API. Una de las ventajas de los esquemas de autenticación basados en tokens web JSON (JWT) es que permiten aprovechar las declaraciones del JWT para implementar ese nivel de control de acceso. Los permisos se pueden codificar como declaraciones personalizadas, que los propietarios de las API pueden utilizar para controlar el acceso a sus API. Una vez que el proxy de la API ha validado el JWT, puede acceder a todos los campos del token como variables y basar en ellos las decisiones de acceso.

En una publicación anterior, analizamos cómo API Connectivity Manager puede ayudar a los operadores y desarrolladores a colaborar mejor. Los equipos de las distintas líneas de negocio que poseen y gestionan las API necesitan un 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 la autenticación y autorización de API, así como requisitos de seguridad adicionales. En este artículo mostramos cómo los propietarios de API pueden utilizar la política Access Control Routing para aplicar un control granular a rutas específicas y ajustarlo aún más para que se aplique por método HTTP y por ruta en función de determinadas declaraciones del token.

Requisitos previos

Debe disponer de una suscripción de prueba o de pago a F5 NGINX Management Suite, que incluye Instance Manager y API Connectivity Manager, además de NGINX Plus como puerta de enlace de API y NGINX App Protect para proteger sus API. Para empezar, 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

Supongamos que hemos publicado un proxy de API de almacén con varios endpoints, como inventory, orders, etc. Ahora queremos incorporar un nuevo servicio llamado pricing, pero queremos que solo puedan acceder a él unos pocos clientes que se hayan inscrito en una prueba beta. Estos clientes se identifican mediante una declaración denominada betatester. En este token de acceso de ejemplo, dicha declaración tiene el valor true para el usuario identificado en la declaración sub, user1@abc.com.

Header
{
  "kid": "123WoAbc4xxxX-o8LiartvSA9zzzzzLIiAbcdzYx",
  "alg": "RS256"
}
Payload

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

Para user2@abc.com, que no fue seleccionado para el programa beta, la notificación betatester se establece en
false:

"sub": "user2@abc.com","betatester": false,

Ahora configuramos la política de enrutamiento de control de acceso (access-control-routing) para conceder acceso al servicio de pricing a los usuarios cuyo JWT contenga la declaración betatester con el valor true.

Para mayor brevedad, mostramos únicamente 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.

"policies": {  "access-control-routing": [
    {
      "action": {
        "conditions": [
          {
            "allowAccess": {
              "uri": "/pricing"
            },
            "when": [
              {
                "key": "token.betatester",
                  "matchOneOf": {
                    "values": [
                      "true"
                    ]
                  }
              }
            ]
          }
        ],
        "returnCode": 403
      }
    }
  ]
}

Una vez aplicada la política, el proxy de API valida las declaraciones del JWT de los usuarios autenticados y realiza un control de acceso granular 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 access-control-routing para controlar qué usuarios pueden utilizar determinados métodos HTTP. En este ejemplo, el proxy de API solo permite a los administradores (usuarios cuyo token incluye el valor Admin) utilizar el método DELETE.

"policies":{  "access-control-routing":[
    "action":{
      "conditions":[
        {
          "when":[
            {
              "key":"token.{claims}",
              "matchOneOf":{
                "values":[
                  "Admin"
                ]
              }
            }
          ],
          "allowAccess":{
            "uri":"/v1/customer",
            "httpMethods":[
              "DELETE"
            ]
          },
          "routeTo" : {
            "targetBackendLabel" : ""
          }
        }
      ]
    }
  ]
}

Enrutamiento basado en cabeceras

Otro uso de la política access-control-routing consiste en tomar decisiones de enrutamiento en función de los valores de las cabeceras de las solicitudes entrantes. Los propietarios de las API pueden configurar reglas o condiciones que especifiquen los valores de la cabecera que deben coincidir para que se enrute la solicitud. Las solicitudes se reenvían si contienen la cabecera y se descartan si no la contienen.

En este ejemplo, una solicitud se dirige al endpoint /seasons solo cuando la cabecera de solicitud version tiene el valor v1. El valor returnCode especifica el código de error que se devolverá cuando version no sea v1 ; en este caso, es 403 (Prohibido).

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

En esta solicitud de ejemplo de curl, enviamos una solicitud al servicio seasons con el encabezado version establecido en v2:

curl -H "version: v2" http://example.com/seasons

Dado que el valor de la cabecera version no es v1, tal como exige la política, el servicio devuelve el código de estado 403.

Inclusión de varias reglas en la política

Puede incluir varias reglas en una política de enrutamiento de control de acceso para controlar el enrutamiento en función de uno, dos o los tres criterios tratados en esta publicación: las declaraciones JWT, los métodos válidos y los valores de las cabeceras de solicitud. Para que una solicitud se enrute, debe cumplir las condiciones de todas las reglas; 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 mediante políticas a nivel de API que aplican un control de acceso granular y toman decisiones de enrutamiento dinámico.

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

Sobre el autor

Veena Raja Rathna

Más artículos de Veena Raja Rathna