Ejemplos de proxy configurable

Esta página se aplica a Apigee y Apigee Hybrid.

Consulta la documentación de Apigee Edge.

El esquema configurable de proxy de API ^{VISTA PREVIA} proporciona una serie de opciones para agregar funciones al proxy. En las siguientes secciones, se proporcionan ejemplos de opciones de configuración de proxy que se usan para admitir casos de uso comunes. Puedes encontrar información más detallada sobre las opciones de configuración en la página de referencia del esquema ApiConfig. El esquema ApiConfig se usa para estructurar el archivo YAML que define un proxy configurable.

El desarrollo de proxy de API configurable de ^{VISTA PREVIA} está disponible solo para clientes con organizaciones de suscripción pagada de Apigee. Los clientes de Apigee con organizaciones de prepago pueden crear proxies de API programables.

Proxy de transferencia

El modelo de configuración más simple para un proxy de API de ^{VISTA PREVIA} configurable es la configuración del proxy de transferencia. En esta configuración, el proxy recibe el tráfico en un basePath y enruta la información a un destino de backend.

Por ejemplo:

#config.yaml
basepath: "/helloworld"

target:
  uri: https://mocktarget.apigee.net

En este ejemplo, la primera línea de la configuración contiene la ruta base. Este es un parámetro obligatorio.

La sección de reglas de la configuración contiene el extremo de destino para enrutar todas las solicitudes entrantes. Este ejemplo de paquete de proxy no aplica información de seguridad ni de enrutamiento para extremos adicionales.

Nota: La configuración anterior es solo con fines ilustrativos. Los proxies que no contienen operaciones mostrarán un código de error 404. Para obtener más información, consulta los problemas conocidos de Apigee

Proxy con operaciones

En este ejemplo, la configuración declara operaciones (o combinaciones de método y ruta) para que un desarrollador de proxy de API pueda implementar diferentes acciones o aplicar políticas diferentes, según la operación solicitada.

Por ejemplo:

#config.yaml
basepath: "/helloworld"

target:
  uri: https://mocktarget.apigee.net

operations:  # First match wins
- id: help
  http_match:
  - path_template: "/help"
    method: GET
- id: status
  http_match:
  - path_template: "/status/*" # A single "*" matches a single path segment
    method: GET

En este ejemplo, la sección de operaciones de la configuración funciona de manera similar a las condiciones de flujo en un paquete de proxy programable. Si deseas obtener más información para usar las condiciones del flujo, consulta Ejecuta código de manera condicional con un flujo condicional.

Proxy con aplicación de seguridad

Una parte importante de la seguridad de las API implica controlar el acceso a las API, acceder a los datos sensibles encriptados en el entorno de ejecución y enmascararlos, y proteger los servicios de backend contra el acceso directo. Con los proxies de API de ^{VISTA PREVIA} configurables, se pueden implementar varias opciones de aplicación de la seguridad, como se detalla en los siguientes ejemplos.

Habilita la verificación de la clave de API

En este ejemplo, la configuración habilita la verificación de la clave de API para todas las operaciones expuestas. La regla para aplicar la verificación de la clave de API se conoce como consumer_authorization. Esta regla de configuración verifica la presencia de una clave de API en una ubicación determinada. Si hay una clave de API, la regla verifica su validez y si esta tiene acceso a la API (es decir, si la clave de la API se suscribe a un producto de API con acceso al proxy de API).

Por ejemplo:

#config.yaml
basepath: "/helloworld"

operations:
- id: help
  http_match:
  - path_template: "/help"
    method: GET
- id: status
  http_match:
  - path_template: "/status/*"
    method: GET

target:
  uri: https://mocktarget.apigee.net

consumer_authorization:  # API Key enforcement
  locations:
  - header: x-api-key

Como la regla consumer_authorization se encuentra en la sección global del proxy, la regla se aplica a todas las operaciones en el paquete de proxy.

Habilita OAuth

Existen dos aspectos a fin de habilitar OAuth para los proxies de API ^{VISTA PREVIA} configurables:

Obtén un token de acceso de OAuth
Valida y otorga acceso a las API

Cada aspecto se describe en las siguientes secciones.

Obtén un token de acceso de OAuth

El proceso de obtener tokens de acceso de OAuth para un proxy configurable es el mismo que para un proxy programable. Los tokens de acceso de OAuth se obtienen mediante paquetes de proxy de API programables. Si deseas obtener ejemplos de los pasos necesarios para configurar una política OAuth2, consulta Solicita tokens de acceso y códigos de autorización.

Valida y autoriza el acceso a las API

Sigue estos pasos para validar y autorizar los tokens de acceso de OAuth con Apigee:

Define el requisito de autenticación de JWT. En esta sección se define cómo el proxy valida un token JWT.

Por ejemplo:

#config.yaml
authentication:
  jwt:
    id: apigee_oauth
    audiences: ["developer-app1"]
    issuer: "SERVICE_ACCOUNT_EMAIL"
    remote_jwks:
      uri: "https://www.googleapis.com/service_accounts/v1/jwk/serviceaccount"
      cache_duration: 600s
    locations:
    - header: Authorization
      transformation:
        template: "Bearer {token}"
        substitution: "{token}"

target:
  uri: https://mocktarget.apigee.net

consumer_authorization:
  locations:
  - jwt_claim:
      requirement: apigee_oauth
      name: client_id

Define la ubicación del ID de cliente de Apigee que se usa para acceder a la API. Por lo general, es una reclamación JWT que contiene la credencial que Apigee usa para autorizar el acceso a los productos de API por parte de las aplicaciones de desarrollador.

Por ejemplo:

#config.yaml
authentication:
  jwt:
    id: apigee_oauth
    audiences: ["developer-app1"]
    issuer: "SERVICE_ACCOUNT_EMAIL"
    remote_jwks:
      uri: "https://www.googleapis.com/service_accounts/v1/jwk/serviceaccount"
      cache_duration: 600s
    locations:
    - header: Authorization
      transformation:
        template: "Bearer {token}"
        substitution: "{token}"

target:
  uri: https://mocktarget.apigee.net

consumer_authorization:
  locations:
  - jwt_claim:
      requirement: apigee_oauth
      name: client_id

La configuración combinada para validar y autorizar el acceso a la API aparecerá de la siguiente manera:

#config.yaml
authentication:
  jwt:
      id: apigee_oauth
      audiences: ["developer-app1"]
      issuer: "SERVICE_ACCOUNT_EMAIL"
      remote_jwks:
        uri: "https://www.googleapis.com/service_accounts/v1/jwk/serviceaccount"
        cache_duration: 600s
      locations:
      - header: Authorization
        transformation:
          template: "Bearer {token}"
          substitution: "{token}"

target:
  uri: https://mocktarget.apigee.net

consumer_authorization:
  locations:
  - jwt_claim:
      requirement: apigee_oauth
      name: client_id

Esta configuración del proxy garantiza que todas las solicitudes al extremo de destino contengan lo siguiente:

Un JWT que cumple con los siguientes criterios:
- Tiene un issuer y un audiences que coinciden.
- Verifica el contenido del URI de JWKS
- Está presente en el encabezado Authorization
Las credenciales de cliente se encuentran en la reclamación apigee_oauth coincidente de JWT client_id

Habilita CORS

En este ejemplo, la configuración del proxy define reglas para habilitar CORS. CORS (uso compartido de recursos entre dominios) es un mecanismo estándar que permite que las llamadas XMLHttpRequest (XHR) de JavaScript que se ejecutan en una página web interactúen con recursos de dominios que no son de origen, CORS es una solución implementada con frecuencia en la política del mismo origen que aplican todos los navegadores.

Por ejemplo:

#config.yaml
basepath: "/helloworld"

cors:
  allow_origins:
  - "*"
  allow_methods:
  - "GET"
  allow_headers:
  - "Accept"
  max_age: 600
  allow_credentials: false

operations:
- id: help
  http_match:
  - path_template: "/help"
    method: GET
- id: status
  http_match:
  - path_template: "/status/*"
    method: GET

target:
  uri: https://mocktarget.apigee.net

Usa servidores de destino

El modelo de proxy configurable admite el concepto de Apigee de servidores de destino. Usar servidores de destino te permite separar los extremos concretos de los extremos de destino para admitir el balanceo de cargas y la conmutación por error en varias instancias de servidor de backend. A fin de usar servidores de destino en una implementación de archivo, usa los siguientes ejemplos para los archivos config.yaml y targetservers.json:

#config.yaml
basepath: "/mock"

operations:
- id: user
  http_match:
  - path_template: "/user"
    method: "GET"

target:
  target_server_id: mocktarget

En el archivo targetservers.json:

[
    {
        "name": "mocktarget",
        "host": "mocktarget.apigee.net",
        "port": 443,
        "isEnabled" : true,
        "sSLInfo": {
            "enabled": true
        }
    }
]

Operaciones de ruta a destinos

En este ejemplo, el modelo de proxy de configuración permite a los usuarios enrutar cada operación a un extremo de destino diferente.

Por ejemplo:

#config.yaml
basepath: "/mockhttpbin"

operations:
- id: user
  http_match:
  - path_template: "/user"
    method: "GET"
  target:
    target_server_id: mocktarget
- id: ip
  http_match:
  - path_template: "/ip"
    method: "GET"
  target:
    uri: https://httpbin.org