Product-apim: In-Memory-Abonnement-Validierung

@isharac

Laden Sie die für die Abonnementvalidierung erforderlichen Informationen in den Speicher beim Serverstart und beim Laden des Mandanten für Mandanten.

In der PR wso2/carbon-apimgt#8563 sind die Dienste derzeit nicht gesichert. Wie werden diese Dienste gesichert? Basic-Authentifizierung oder OAuth?

@isharac @chamilaadhi
Auch mit dieser Änderung verlieren wir genau welche Attribute unterhalb der Nutzlasten von JWT und Schlüsselvalidierungsantworten.

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

Laden Sie die für die Abonnementvalidierung erforderlichen Informationen in den Speicher beim Serverstart und beim Laden des Mandanten für Mandanten.

In der PR wso2/carbon-apimgt#8563 sind die Dienste derzeit nicht gesichert. Wie werden diese Dienste gesichert? Basic-Authentifizierung oder OAuth?

Dies ist mit Basic Auth gesichert.

@praminda wir haben nach dieser Änderung nur noch Standard-JWT-Ansprüche in einem JWT, das vom Oauth-Anbieter stammt

In Ordnung. Wir verlieren also die folgenden Attribute von JWT,

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

und nur die folgenden Attribute sind in der Schlüsselvalidierungsantwort verfügbar . Hab ich recht?

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

Dies ist implementiert.

Gibt es Überlegungen, ob der Benutzer dieses Verhalten konfigurieren kann oder nicht? Würde viel lieber alle Informationen in einem JWT abrufen können, als sich auf JMS-Abonnements zu verlassen, um auf dem neuesten Stand zu bleiben. Oder zumindest eine Möglichkeit, ein JWT mit allen Abonnements aus der Datenbank zu generieren? (Besonders bei Verwendung zusammen mit micro-gw).

Hallo @christian-morin
Wir haben nicht vor, es konfigurierbar zu machen, da dies jetzt das Standardverhalten ist.
Und der Schlüsselmanager eines Drittanbieters kennt keine Abonnementmetadaten (da die DB nicht freigegeben wird), kann das aus dem KM des Drittanbieters generierte JWT nicht in die Abonnementdaten aufgenommen werden.

Wenn Sie uns Ihre spezifischen Anforderungen mitteilen, können wir vielleicht eine Lösung finden.

Voraussetzung für uns ist, neben dem APIM auch das Micro-Gateway zu nutzen. Die Benutzer generieren das JWT im APIM und verwenden es, um Zugriff auf die einzelnen Micro-GW:s zu erhalten. Bisher waren alle abonnierten APIs in den JWT-Metadaten vorhanden und konnten vom Micro-GW "offline" verifiziert werden. Dieses neue Setup erfordert, dass alle unsere Micro-GW-Instanzen auf das JMS-Abonnement hören, um auf dem Laufenden zu bleiben? (und keine Möglichkeit, im JWT zu überprüfen, welche Abonnements für den Client verfügbar sind)

Ich denke nur, dass es bei potenziell Hunderten von Micro-GW:s ein Kinderspiel sein wird, zu debuggen, warum jemand eine 401 bekommt ... hat sich das Thema nicht registriert, müssen wir das Micro-GW neu starten, um es zu machen Laden Sie alle Subskriptions-Metadaten herunter, was passiert, wenn das APIM nicht reagiert, wenn das Micro-GW startet usw. Das Anhängen aller

Hallo @christian-morin
Um Ihren Anwendungsfall zu unterstützen, können wir 2 Optionen anbieten.

Option 1:
Verwenden Sie APIM 3.1.0 mit MG 3.2.0

Option 2:
Verwenden Sie API-M 3.2.0 und passen Sie den TokenIssuer wie in [1] beschrieben an.
In diesem Fall müssen Sie die APIM-Datenbank für den Key Manager-Knoten freigeben und können die erforderlichen Ansprüche im JWT hinzufügen.

Hoffe das hilft!
[1] https://is.docs.wso2.com/en/latest/learn/extension-points-for-oauth/#oauth -token-generator

Hallo @isharac

Danke für Ihre Antwort. Ich gehe davon aus, dass Option 1 keine sehr gute langfristige Lösung ist, da wir das Produkt dann nie aktualisieren können? ;)

Ich vermutete, dass wir einen angepassten TokenIssuer schreiben müssten, wie Sie es vorschlagen, aber ich bin froh zu wissen, dass dies möglich sein sollte. Danke schön.