Product-apim: Validación de suscripción en memoria

Creado en 3 jun. 2020  ·  11Comentarios  ·  Fuente: wso2/product-apim

Describe tu (s) problema (s)

Para la validación de la suscripción, la puerta de enlace llama al servicio de validación de claves que se ejecuta en el nodo del administrador de claves, y el administrador de claves accede a la base de datos para recuperar los datos necesarios para la validación.

en caso de falla de la base de datos, existe la posibilidad de que falle una solicitud en tiempo de ejecución.

Describe tu solución

cargar la información requerida para la validación de la suscripción en la memoria al iniciar el servidor y al cargar los inquilinos para los inquilinos.
Para cualquier actualización, como la creación de aplicaciones, agregue una suscripción, se notificará a través de eventos al administrador de tráfico.
Gateway se suscribirá a este evento a través de un tema.

¿Cómo lo implementarás?


PrioritNormal TypNew Feature

Comentario más útil

El requisito para nosotros es utilizar el Micro-Gateway junto con el APIM. Los usuarios generan el JWT en el APIM y lo utilizan para obtener acceso a los Micro-GW individuales. Anteriormente, todas las API suscritas estaban presentes en los metadatos de JWT y podían ser verificadas "fuera de línea" por Micro-GW. Esta nueva configuración requiere que todas nuestras instancias Micro-GW escuchen la suscripción JMS para mantenerse al día. (y no hay forma de verificar en el JWT qué suscripciones están disponibles para el cliente)

Solo estoy pensando que con potencialmente cientos de micro-GW: s será un desastre depurar por qué alguien está obteniendo un 401 ... si el tema no se registró, ¿necesitamos reiniciar el Micro-GW para hacerlo? descargar todos los metadatos de suscripción, qué sucede si el APIM no responde cuando se inicia el Micro-GW, etc. Tener todos los subs cribedAPI: sy metadatos adjuntos en los metadatos de JWT hizo que la solución fuera mucho más "robusta" y Micro-GW: s no tenía ningún vínculo con el APIM ya que el JWT tenía toda la información (y el cliente podía verificar por sí mismo en los metadatos del JWT a qué suscripciones tenían acceso con la clave). Entonces, todo lo que quiero es una forma de generar el antiguo comportamiento JWT para usar con nuestros Micro-GW: s. ¿Quizás será posible extendiendo alguna clase de generador JWT para APIM? (¿O este nuevo manejo hará que sea muy difícil de lograr?)

Todos 11 comentarios

@isharac

cargar la información requerida para la validación de la suscripción en la memoria al iniciar el servidor y al cargar los inquilinos para los inquilinos.

En el PR wso2 / carbon-apimgt # 8563 los servicios no están asegurados por el momento. ¿Cómo se asegurarán estos servicios? ¿Autenticación básica u OAuth?

@isharac @chamilaadhi
Además, con este cambio, exactamente qué atributos perdemos por debajo de JWT y cargas útiles de respuesta de validación de claves.


JWT:

{
  "aud": "http://org.wso2.apimgt/gateway",
  "sub": "[email protected]",
  "application": {
    "owner": "admin",
    "tierQuotaType": "requestCount",
    "tier": "10PerMin",
    "name": "New App",
    "id": 2,
    "uuid": null
  },
  "scope": "am_application_scope default",
  "iss": "https://localhost:9443/oauth2/token",
  "tierInfo": {
    "Unlimited": {
      "tierQuotaType": "requestCount",
      "stopOnQuotaReach": true,
      "spikeArrestLimit": 0,
      "spikeArrestUnit": null
    }
  },
  "keytype": "PRODUCTION",
  "subscribedAPIs": [
    {
      "subscriberTenantDomain": "carbon.super",
      "name": "PizzaShackAPI",
      "context": "/pizzashack/1.0.0",
      "publisher": "admin",
      "version": "1.0.0",
      "subscriptionTier": "Unlimited"
    }
  ],
  "consumerKey": "some_value",
  "exp": 3738643151,
  "iat": 1591159504,
  "jti": "some_valu2"
}


Respuesta de validación clave

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
    <soapenv:Body>
        <ns:validateKeyResponse xmlns:ns="http://org.apache.axis2/xsd">
            <ns:return xmlns:ax2129="http://keymgt.apimgt.carbon.wso2.org/xsd"
                       xmlns:ax2131="http://api.apimgt.carbon.wso2.org/xsd"
                       xmlns:ax2133="http://dto.impl.apimgt.carbon.wso2.org/xsd"
                       xmlns:ax2135="http://model.api.apimgt.carbon.wso2.org/xsd"
                       xmlns:ax2136="http://dto.api.apimgt.carbon.wso2.org/xsd"
                       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="ax2133:APIKeyValidationInfoDTO">
                <ax2133:apiName>$APINAME</ax2133:apiName>
                <ax2133:apiPublisher>admin</ax2133:apiPublisher>
                <ax2133:apiTier xsi:nil="true" />
                <ax2133:applicationId>$APPLICATION_ID</ax2133:applicationId>
                <ax2133:applicationName>$APPLICATION_NAME</ax2133:applicationName>
                <ax2133:applicationTier>$APPLICATION_TIER</ax2133:applicationTier>
                <ax2133:authorized>true</ax2133:authorized>
                <ax2133:authorizedDomains xsi:nil="true" />
                <ax2133:consumerKey>fxzmLefepgKF2Qa</ax2133:consumerKey>
                <ax2133:contentAware>false</ax2133:contentAware>
                <ax2133:endUserName>[email protected]</ax2133:endUserName>
                <ax2133:endUserToken xsi:nil="true" />
                <ax2133:issuedTime>15288163</ax2133:issuedTime>
                <ax2133:scopes>default</ax2133:scopes>
                <ax2133:scopes>am_application_scope</ax2133:scopes>
                <ax2133:spikeArrestLimit>0</ax2133:spikeArrestLimit>
                <ax2133:spikeArrestUnit xsi:nil="true" />
                <ax2133:stopOnQuotaReach>true</ax2133:stopOnQuotaReach>
                <ax2133:subscriber>admin</ax2133:subscriber>
                <ax2133:subscriberTenantDomain>carbon.super</ax2133:subscriberTenantDomain>
                <ax2133:throttlingDataList>api_level_throttling_key</ax2133:throttlingDataList>
                <ax2133:tier>$TIER</ax2133:tier>
                <ax2133:type>$KEY_TYPE</ax2133:type>
                <ax2133:userType>APPLICATION</ax2133:userType>
                <ax2133:validationStatus>0</ax2133:validationStatus>
                <ax2133:validityPeriod>9223376854775807</ax2133:validityPeriod>
            </ns:return>
        </ns:validateKeyResponse>
    </soapenv:Body>
</soapenv:Envelope>

@isharac

cargar la información requerida para la validación de la suscripción en la memoria al iniciar el servidor y al cargar los inquilinos para los inquilinos.

En el PR wso2 / carbon-apimgt # 8563 los servicios no están asegurados por el momento. ¿Cómo se asegurarán estos servicios? ¿Autenticación básica u OAuth?

Esto está asegurado con autenticación básica.

@praminda , solo tendremos reclamos de JWT estándar en un JWT proveniente del proveedor de Oauth después de este cambio

Está bien. Así que perderemos los siguientes atributos de JWT,

"application": {},
"tierInfo": {},
"keytype": "",
"subscribedAPIs": [],

y solo los siguientes atributos estarán disponibles en la respuesta de validación de claves. ¿Estoy en lo correcto?

<ax2133:apiName>$APINAME</ax2133:apiName>
<ax2133:apiPublisher>admin</ax2133:apiPublisher>
<ax2133:apiTier xsi:nil="true" />
<ax2133:authorized>true</ax2133:authorized>
<ax2133:authorizedDomains xsi:nil="true" />
<ax2133:consumerKey>fxzmLefepgKF2Qa</ax2133:consumerKey>
<ax2133:contentAware>false</ax2133:contentAware>
<ax2133:endUserName>[email protected]</ax2133:endUserName>
<ax2133:endUserToken xsi:nil="true" />
<ax2133:issuedTime>15288163</ax2133:issuedTime>
<ax2133:scopes>default</ax2133:scopes>
<ax2133:scopes>am_application_scope</ax2133:scopes>
<ax2133:userType>APPLICATION</ax2133:userType>
<ax2133:validationStatus>0</ax2133:validationStatus>
<ax2133:validityPeriod>9223376854775807</ax2133:validityPeriod>

Esto está implementado.

¿Alguna consideración para permitir que el usuario configure este comportamiento o no? Preferiría poder obtener toda la información en un JWT que depender de las suscripciones JMS para mantenerse actualizado. ¿O al menos una forma de generar un JWT con todas las suscripciones de la base de datos? (Específicamente cuando se usa junto con micro-gw).

Hola @ christian-morin
No tenemos planes de hacerlo configurable, ya que este es el comportamiento predeterminado ahora.
Y el administrador de claves de terceros no conoce los metadatos de las suscripciones (ya que la base de datos no se comparte), el JWT generado a partir del KM de terceros no se puede incluir en los datos de suscripción.

Si puede compartir su requisito específico, tal vez podamos encontrar una solución.

El requisito para nosotros es utilizar el Micro-Gateway junto con el APIM. Los usuarios generan el JWT en el APIM y lo utilizan para obtener acceso a los Micro-GW individuales. Anteriormente, todas las API suscritas estaban presentes en los metadatos de JWT y podían ser verificadas "fuera de línea" por Micro-GW. Esta nueva configuración requiere que todas nuestras instancias Micro-GW escuchen la suscripción JMS para mantenerse al día. (y no hay forma de verificar en el JWT qué suscripciones están disponibles para el cliente)

Solo estoy pensando que con potencialmente cientos de micro-GW: s será un desastre depurar por qué alguien está obteniendo un 401 ... si el tema no se registró, ¿necesitamos reiniciar el Micro-GW para hacerlo? descargar todos los metadatos de suscripción, qué sucede si el APIM no responde cuando se inicia el Micro-GW, etc. Tener todos los subs cribedAPI: sy metadatos adjuntos en los metadatos de JWT hizo que la solución fuera mucho más "robusta" y Micro-GW: s no tenía ningún vínculo con el APIM ya que el JWT tenía toda la información (y el cliente podía verificar por sí mismo en los metadatos del JWT a qué suscripciones tenían acceso con la clave). Entonces, todo lo que quiero es una forma de generar el antiguo comportamiento JWT para usar con nuestros Micro-GW: s. ¿Quizás será posible extendiendo alguna clase de generador JWT para APIM? (¿O este nuevo manejo hará que sea muy difícil de lograr?)

Hola @ christian-morin
Para respaldar su caso de uso, podemos ofrecer 2 opciones.

Opción 1:
Utilice APIM 3.1.0 con MG 3.2.0

Opcion 2:
Utilice API-M 3.2.0 y personalice el TokenIssuer como se explica en [1].
En este caso, deberá compartir la base de datos de APIM con el nodo del Administrador de claves y podrá agregar las reclamaciones requeridas en el JWT.

¡Espero que esto ayude!
[1] https://is.docs.wso2.com/en/latest/learn/extension-points-for-oauth/#oauth -token-generator

Hola @isharac

Gracias por la respuesta. Supongo que la Opción 1 no es una solución muy buena a largo plazo, ya que nunca podremos actualizar el producto. ;)

Sospechaba que tendríamos que escribir un TokenIssuer personalizado como sugieres, pero me alegra saber que debería ser posible. Gracias.

¿Fue útil esta página
0 / 5 - 0 calificaciones