Product-apim: Проверка подписки в памяти

Созданный на 3 июн. 2020  ·  11Комментарии  ·  Источник: wso2/product-apim

Опишите вашу проблему (проблемы)

Для проверки подписки шлюз вызывает службу проверки ключей, работающую в узле диспетчера ключей, а диспетчер ключей обращается к базе данных для получения необходимых данных для проверки.

в случае сбоя базы данных существует вероятность сбоя запроса во время выполнения.

Опишите свое решение

информация о загрузке, необходимая для проверки подписки, в память при запуске сервера и при загрузке клиента для клиентов.
Для любых обновлений, таких как создание приложения, добавьте подписку, вы получите уведомление через события в диспетчере трафика.
Шлюз подпишется на это событие через тему.

Как вы это реализуете


PrioritNormal TypNew Feature

Самый полезный комментарий

От нас требуется использовать Micro-Gateway вместе с APIM. Пользователи генерируют JWT в APIM и используют их для получения доступа к отдельным Micro-GW: s. Ранее все подписанные API присутствовали в метаданных JWT и могли быть проверены Micro-GW в автономном режиме. Эта новая установка требует, чтобы все наши экземпляры Micro-GW слушали подписку JMS, чтобы быть в курсе? (и нет возможности проверить в JWT, какие подписки доступны клиенту)

Я просто думаю, что с потенциально сотнями микро-GW: s будет хлопотно отлаживать, почему кто-то получает 401 ... не была ли Тема не зарегистрирована, нужно ли нам перезапускать Micro-GW, чтобы сделать это? загрузите все метаданные подписки, что произойдет, если APIM не отвечает при запуске Micro-GW и т. д. Наличие всех подписок API и метаданных, прикрепленных к метаданным JWT, сделало решение гораздо более «надежным» и Micro-GW: s не имел никаких связей с APIM, поскольку JWT содержал всю информацию (и клиент мог сам проверять в метаданных JWT, к каким подпискам он имел доступ с помощью ключа). Итак, все, что мне нужно, это способ сгенерировать старый JWT поведения для использования с нашим Micro-GW: s. Может быть, удастся расширить какой-нибудь JWT-Generator-класс для APIM? (Или из-за этого нового подхода сделать это будет очень сложно?)

Все 11 Комментарий

@isharac

информация о загрузке, необходимая для проверки подписки, в память при запуске сервера и при загрузке клиента для клиентов.

В PR wso2 / carbon-apimgt # 8563 услуги на данный момент не защищены. Как эти услуги будут защищены? Базовая авторизация или OAuth?

@isharac @chamilaadhi
Также с этим изменением, какие именно атрибуты мы теряем из-за полезной нагрузки ответа JWT и проверки ключа.


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


Ответ проверки ключа

<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

информация о загрузке, необходимая для проверки подписки, в память при запуске сервера и при загрузке клиента для клиентов.

В PR wso2 / carbon-apimgt # 8563 услуги на данный момент не защищены. Как эти услуги будут защищены? Базовая авторизация или OAuth?

Это обеспечивается базовой аутентификацией.

@praminda у нас будут только стандартные утверждения JWT в JWT, поступившие от поставщика Oauth после этого изменения

В порядке. Итак, мы потеряем следующие атрибуты из JWT,

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

и только следующие атрибуты будут доступны в ответе на проверку ключа. Я прав?

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

Это реализовано.

Какие-либо соображения, позволяющие пользователю настраивать это поведение или нет? Я бы предпочел получить всю информацию в JWT, чем полагаться на JMS-подписки для поддержания актуальности. Или хотя бы способ сгенерировать JWT со всеми подписками из базы данных? (Особенно при использовании вместе с micro-gw).

Привет @ christian-morin
У нас нет планов делать его настраиваемым, так как сейчас это поведение по умолчанию.
А сторонний диспетчер ключей не знает метаданных подписок (поскольку БД не используется совместно), JWT, сгенерированный сторонним KM, не может включать данные подписки.

Если вы поделитесь своими конкретными требованиями, возможно, мы найдем решение.

От нас требуется использовать Micro-Gateway вместе с APIM. Пользователи генерируют JWT в APIM и используют их для получения доступа к отдельным Micro-GW: s. Ранее все подписанные API присутствовали в метаданных JWT и могли быть проверены Micro-GW в автономном режиме. Эта новая установка требует, чтобы все наши экземпляры Micro-GW слушали подписку JMS, чтобы быть в курсе? (и нет возможности проверить в JWT, какие подписки доступны клиенту)

Я просто думаю, что с потенциально сотнями микро-GW: s будет хлопотно отлаживать, почему кто-то получает 401 ... не была ли Тема не зарегистрирована, нужно ли нам перезапускать Micro-GW, чтобы сделать это? загрузите все метаданные подписки, что произойдет, если APIM не отвечает при запуске Micro-GW и т. д. Наличие всех подписок API и метаданных, прикрепленных к метаданным JWT, сделало решение гораздо более «надежным» и Micro-GW: s не имел никаких связей с APIM, поскольку JWT содержал всю информацию (и клиент мог сам проверять в метаданных JWT, к каким подпискам он имел доступ с помощью ключа). Итак, все, что мне нужно, это способ сгенерировать старый JWT поведения для использования с нашим Micro-GW: s. Может быть, удастся расширить какой-нибудь JWT-Generator-класс для APIM? (Или из-за этого нового подхода сделать это будет очень сложно?)

Привет @ christian-morin
Для поддержки вашего варианта использования мы можем предложить 2 варианта.

Опция 1:
Используйте APIM 3.1.0 с MG 3.2.0

Вариант 2:
Используйте API-M 3.2.0 и настройте TokenIssuer, как описано в [1].
В этом случае вам нужно будет поделиться базой данных APIM с узлом Key Manager и вы сможете добавить необходимые утверждения в JWT.

Надеюсь это поможет!
[1] https://is.docs.wso2.com/en/latest/learn/extension-points-for-oauth/#oauth -token-generator

Привет @isharac

Спасибо за ответ. Я полагаю, что вариант 1 - не очень хорошее долгосрочное решение, поскольку в таком случае мы никогда не сможем обновить продукт? ;)

Я подозревал, что нам придется написать индивидуализированный TokenIssuer, как вы предлагаете, но был рад узнать, что это возможно. Спасибо.

Была ли эта страница полезной?
0 / 5 - 0 рейтинги