Product-apim: التحقق من صحة الاشتراك في الذاكرة

تم إنشاؤها على ٣ يونيو ٢٠٢٠  ·  11تعليقات  ·  مصدر: wso2/product-apim

صِف مشكلتك (مشاكلك)

للتحقق من صحة الاشتراك ، تستدعي البوابة خدمة التحقق من صحة المفتاح التي تعمل في عقدة مدير المفاتيح ، ويقوم مدير المفاتيح بالوصول إلى قاعدة البيانات لاسترداد البيانات المطلوبة للتحقق من الصحة.

في حالة فشل قاعدة البيانات ، هناك فرصة لفشل الطلب في وقت التشغيل.

صِف حلك

تحميل المعلومات المطلوبة للتحقق من صحة الاشتراك في الذاكرة عند بدء تشغيل الخادم وعند تحميل المستأجر للمستأجرين.
لأية تحديثات مثل إنشاء التطبيق ، إضافة اشتراك ، سيتم إخطار مدير المرور عبر الأحداث.
ستشارك البوابة في هذا الحدث عبر موضوع.

كيف ستنفذها


PrioritNormal TypNew Feature

التعليق الأكثر فائدة

المطلب بالنسبة لنا هو استخدام Micro-Gateway جنبًا إلى جنب مع APIM. ينشئ المستخدمون JWT في APIM ويستخدمونها للوصول إلى Micro-GW: s. في السابق ، كانت جميع واجهات برمجة التطبيقات (APIs) المُشتركة موجودة في بيانات تعريف JWT ويمكن التحقق منها "غير متصل" بواسطة Micro-GW. يتطلب هذا الإعداد الجديد جميع مثيلات Micro-GW الخاصة بنا للاستماع إلى اشتراك JMS لمواكبة التحديثات؟ (ولا توجد طريقة للتحقق في JWT من الاشتراكات المتاحة للعميل)

أنا أفكر فقط أنه مع وجود المئات من micro-GW: s ، سيكون من الصعب تصحيح سبب حصول شخص ما على 401 ... هل لم يتم تسجيل الموضوع ، هل نحتاج إلى إعادة تشغيل Micro-GW لتحقيق ذلك تحميل جميع الاشتراك الفوقية، ماذا يحدث إذا كان APIM لا يستجيب عندما الصغرى، GW بدأ الخ بعد كل الغواصات cribedAPI: الصورة والبيانات الوصفية المرفقة في JWT الفوقية جعل حل أكثر من ذلك بكثير "قوية" و لم يكن لدى Micro-GW: أي علاقات مع APIM لأن JWT احتفظ بجميع المعلومات (ويمكن للعميل أن يتحقق بنفسه في JWT-metadata من الاشتراكات التي كان لديهم إمكانية الوصول إليها باستخدام المفتاح). لذلك كل ما أريده هو طريقة لتوليد السلوك القديم JWT لاستخدامه مع Micro-GW: s. ربما سيكون ذلك ممكنًا من خلال توسيع فئة JWT-Generator لـ APIM؟ (أم أن هذا الأسلوب الجديد سيجعل من الصعب جدًا تحقيق ذلك؟)

ال 11 كومينتر

isharac

تحميل المعلومات المطلوبة للتحقق من صحة الاشتراك في الذاكرة عند بدء تشغيل الخادم وعند تحميل المستأجر للمستأجرين.

في PR wso2 / carbon-apimgt # 8563 ، لا يتم تأمين الخدمات في الوقت الحالي. كيف سيتم تأمين هذه الخدمات؟ المصادقة الأساسية أم OAuth؟

تضمين التغريدة
مع هذا التغيير أيضًا ، ما هي السمات التي نفقدها بالضبط من أقل من 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. في السابق ، كانت جميع واجهات برمجة التطبيقات (APIs) المُشتركة موجودة في بيانات تعريف JWT ويمكن التحقق منها "غير متصل" بواسطة Micro-GW. يتطلب هذا الإعداد الجديد جميع مثيلات Micro-GW الخاصة بنا للاستماع إلى اشتراك JMS لمواكبة التحديثات؟ (ولا توجد طريقة للتحقق في JWT من الاشتراكات المتاحة للعميل)

أنا أفكر فقط أنه مع وجود المئات من micro-GW: s ، سيكون من الصعب تصحيح سبب حصول شخص ما على 401 ... هل لم يتم تسجيل الموضوع ، هل نحتاج إلى إعادة تشغيل Micro-GW لتحقيق ذلك تحميل جميع الاشتراك الفوقية، ماذا يحدث إذا كان APIM لا يستجيب عندما الصغرى، GW بدأ الخ بعد كل الغواصات cribedAPI: الصورة والبيانات الوصفية المرفقة في JWT الفوقية جعل حل أكثر من ذلك بكثير "قوية" و لم يكن لدى Micro-GW: أي علاقات مع APIM لأن JWT احتفظ بجميع المعلومات (ويمكن للعميل أن يتحقق بنفسه في JWT-metadata من الاشتراكات التي كان لديهم إمكانية الوصول إليها باستخدام المفتاح). لذلك كل ما أريده هو طريقة لتوليد السلوك القديم JWT لاستخدامه مع Micro-GW: s. ربما سيكون ذلك ممكنًا من خلال توسيع فئة JWT-Generator لـ APIM؟ (أم أن هذا الأسلوب الجديد سيجعل من الصعب جدًا تحقيق ذلك؟)

مرحبًا @ christian-morin
لدعم حالة الاستخدام الخاصة بك ، يمكننا الخروج بخيارين.

الخيار 1:
استخدم APIM 3.1.0 مع MG 3.2.0

الخيار 2:
استخدم API-M 3.2.0 وقم بتخصيص مصدر الرمز كما هو موضح في [1].
في هذه الحالة ، ستحتاج إلى مشاركة APIM db مع عقدة Key Manager وستكون قادرًا على إضافة المطالبات المطلوبة في JWT.

أتمنى أن يساعدك هذا!
[1] https://is.docs.wso2.com/en/latest/learn/extension-points-for-oauth/#oauth -token-generator

مرحبًا isharac

شكرا لكم على الرد. أفترض أن الخيار 1 ليس حلاً جيدًا طويل الأجل حيث لا يمكننا بعد ذلك ترقية المنتج أبدًا؟ ؛)

كنت أظن أنه سيتعين علينا كتابة مُصدر رمز مخصص كما تقترح ، ولكن يسعدني معرفة أنه من الممكن أن يكون ذلك ممكنًا. شكرا لك.

هل كانت هذه الصفحة مفيدة؟
0 / 5 - 0 التقييمات