Product-apim: Validation de l'abonnement en mémoire

@isharac

charger les informations requises pour la validation de l'abonnement dans la mémoire au démarrage du serveur et au chargement du locataire pour les locataires.

Dans le PR wso2/carbon-apimgt#8563, les services ne sont pas sécurisés pour le moment. Comment ces services seront-ils sécurisés ? Authentification de base ou OAuth ?

@isharac @chamilaadhi
De plus, avec ce changement, quels attributs perdons-nous exactement des charges utiles de réponse de validation de clé et de JWT inférieurs.

{
  "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"
}

<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

charger les informations requises pour la validation de l'abonnement dans la mémoire au démarrage du serveur et au chargement du locataire pour les locataires.

Dans le PR wso2/carbon-apimgt#8563, les services ne sont pas sécurisés pour le moment. Comment ces services seront-ils sécurisés ? Authentification de base ou OAuth ?

Ceci est sécurisé avec l'authentification de base.

@praminda, nous

D'accord. Nous allons donc perdre les attributs ci-dessous de JWT,

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

et seuls les attributs suivants seront disponibles dans la réponse de validation de clé. Ai-je raison?

<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>

Ceci est mis en œuvre.

Des considérations pour permettre à l'utilisateur de configurer ce comportement ou non ? Je préférerais de loin pouvoir obtenir toutes les informations dans un JWT plutôt que de compter sur les abonnements JMS pour rester à jour. Ou au moins un moyen de générer un JWT avec tous les abonnements de la base de données ? (Spécifiquement lorsqu'il est utilisé avec micro-gw).

Salut @christian-morin
Nous n'avons pas l'intention de le rendre configurable car c'est le comportement par défaut maintenant.
Et le gestionnaire de clés tiers ne connaît pas les métadonnées des abonnements (car la base de données n'est pas partagée), le JWT généré à partir du KM tiers ne peut pas être inclus dans les données d'abonnement.

Si vous pouvez partager vos besoins spécifiques, nous pouvons peut-être trouver une solution.

L'exigence pour nous est d'utiliser la Micro-Gateway aux côtés de l'APIM. Les utilisateurs génèrent le JWT dans l'APIM et les utilisent pour accéder aux Micro-GW:s individuels. Auparavant, toutes les API souscrites étaient présentes dans les métadonnées JWT et pouvaient être vérifiées « hors ligne » par le Micro-GW. Cette nouvelle configuration nécessite que toutes nos instances Micro-GW écoutent l'abonnement JMS pour rester à jour ? (et aucun moyen de vérifier dans le JWT quels abonnements sont disponibles pour le client)

Je pense juste qu'avec potentiellement des centaines de micro-GW:s, il sera difficile de déboguer pourquoi quelqu'un obtient un 401 ... le sujet n'a-t-il pas été enregistré, devons-nous redémarrer le Micro-GW pour le faire télécharger toutes les métadonnées d'abonnement, que se passe-t-il si l'APIM ne répond pas lorsque le Micro-GW démarre, etc. Le fait d'avoir tous les abonnements API:s et métadonnées attachés dans les métadonnées JWT a rendu la solution beaucoup plus "robuste" et le Micro-GW:s n'avait aucun lien avec l'APIM car le JWT détenait toutes les informations (et le client pouvait lui-même vérifier dans les métadonnées JWT à quels abonnements il avait accès avec la clé). Donc, tout ce que je veux, c'est un moyen de générer l'ancien comportement JWT à utiliser avec nos Micro-GW:s. Ce sera peut-être possible en étendant une classe JWT-Generator pour APIM ? (Ou cette nouvelle gestion rendra-t-elle cela très difficile à accomplir ?)

Salut @christian-morin
Pour prendre en charge votre cas d'utilisation, nous pouvons proposer 2 options.

Option 1:
Utiliser APIM 3.1.0 avec MG 3.2.0

Option 2:
Utilisez API-M 3.2.0 et personnalisez le TokenIssuer comme expliqué dans [1].
Dans ce cas, vous devrez partager la base de données APIM avec le nœud Key Manager et pourrez ajouter les revendications requises dans le JWT.

J'espère que cela t'aides!
[1] https://is.docs.wso2.com/en/latest/learn/extension-points-for-oauth/#oauth -token-generator

Salut @isharac

Merci pour la réponse. Je suppose que l'option 1 n'est pas une très bonne solution à long terme car nous ne pourrons alors jamais mettre à niveau le produit ? ;)

Je soupçonnais que nous devions écrire un TokenIssuer personnalisé comme vous le suggérez, mais je suis heureux de savoir que cela devrait être possible. Merci.