استخدام رموز OAuth المميزة التابعة لجهات خارجية

أنت تعرض مستندات Apigee Edge.
انتقل إلى مستندات Apigee X. معلومات

وسنناقش في هذا الموضوع كيفية استيراد رموز الدخول ورموز التحديث التي تم إنشاؤها خارجيًا أو رموز المصادقة في مخزن رموز Edge. يمكنك استخدام هذا الأسلوب إذا كنت ترغب في يُرجى ضبط Apigee Edge للتحقق من صحة الرموز المميّزة التي يتم إنشاؤها خارج Apigee Edge.

في الحالة المعتادة، ستنشئ Apigee Edge رمز OAuth وتخزّنه وتعيده إلى تطبيق الاتصال. بعد ذلك يعرض تطبيق الاتصال الرمز المميّز مرة أخرى في Apigee Edge عند طلب وApigee Edge - من خلال سياسة OAuthV2 بالعملية = VerifyAccessToken - سوف التحقّق من صلاحية الرمز المميّز يوضّح هذا الموضوع طريقة ضبط Apigee Edge على تخزين البيانات رمز OAuth مميز تم إنشاؤه في مكان آخر، مع الإبقاء على جزء التحقق من الرمز المميز كما هو، كما لو تم إنشاء الرمز المميز بواسطة Edge.

مثال

إذا كنت تريد مشاهدة مثال عملي يوضّح الأسلوب الموضحة في هذا الموضوع، ألقِ نظرة على Apigee نموذج إدارة الرموز المميّزة المفوَّضة

What is this?‎

لنفترض أن لديك نظام تفويض قائمًا، وترغب في استخدام القيم التي تم إنشاؤها من خلال هذا النظام بدلاً من قيم رمز OAuth2 أو قيم الرمز التي Edge يولد. يمكنك بعد ذلك إجراء طلبات آمنة للوصول إلى الخادم الوكيل لواجهة برمجة التطبيقات باستخدام الرمز أو الرمز البديل. وستعمل Edge على التحقق من صحتها كما لو كانت من إنشاء Edge.

بعض المعلومات الأساسية

في الحالة المعتادة، تُنشئ Apigee Edge رمزًا مميزًا من خلال إنتاج سلسلة عشوائية من الأحرف. الأرقام. تربط Apigee Edge بهذا الرمز المميّز، وبيانات أخرى مثل وقت إصدار الرمز المميّز. وانتهاء الصلاحية وقائمة منتجات واجهة برمجة التطبيقات التي يكون الرمز المميز صالحًا لها والنطاق. كل هذا يمكن عرض معلومات في رد تم إنشاؤه تلقائيًا بواسطة سياسة OAuthV2 مع العملية = GenerateAccessToken. يبدو الرد كما يلي:

{
  "issued_at": "1469735625687",
  "application_name": "06947a86-919e-4ca3-ac72-036723b18231",
  "scope": "urn://example.com/read",
  "status": "approved",
  "api_product_list": "[implicit-test]",
  "api_product_list_json": ["implicit-test"],
  "expires_in": "1799", //--in seconds
  "developer.email": "joe@weathersample.com",
  "token_type": "BearerToken",
  "client_id": "U9AC66e9YFyI1yqaXgUF8H6b9wUN1TLk",
  "access_token": "zBC90HhCGmGlaMBWeZAai2s3za5j",
  "organization_name": "wwitman",
  "refresh_token_expires_in": "0", //--in seconds
  "refresh_count": "0"
}

قيمة السمة access_token هي مفتاح البحث بشكل فعال بيانات الاستجابة. يمكن لأي تطبيق تقديم طلب إلى خادم وكيل لواجهة برمجة تطبيقات مستضاف في Edge، يحمل رمز الحامل zBC90HhCGmGlaMBWeZAai2s3za5j وEdge - باستخدام OAuthV2 التي لها العملية = VerifyAccessToken - البحث عن الرمز واسترداد جميع المعلومات واستخدام هذه المعلومات لتحديد ما إذا كان الرمز المميز صالحًا أم لا، لخادم وكيل واجهة برمجة التطبيقات المطلوب. تُسمّى هذه العملية التحقّق من صحة الرمز المميّز. تشتمل جميع المعلومات المذكورة أعلاه على الرمز المميز. تشير رسالة الأشكال البيانية access_token طريقة البحث فقط عن تلك المعلومات.

من ناحية أخرى، باتباع الخطوات الموضحة هنا، يمكنك تهيئة Edge على تخزين بحيث تكون قيمة access_token قيمة يتم إنشاؤها بواسطة عنصر خدمة ما. قد تكون جميع بيانات التعريف الأخرى متطابقة. على سبيل المثال، لنفترض أن لديك نظامًا خارجية عن Apigee Edge التي تنشئ رموزًا مميزة بالشكل "TOKEN-16 بشكل عشوائي number>" . في هذه الحالة، قد تكون البيانات الوصفية الكاملة للرموز المميّزة المخزَّنة من خلال Apigee Edge على النحو التالي:

{
  "issued_at": "1469735625687",
  "application_name": "06947a86-919e-4ca3-ac72-036723b18231",
  "scope": "urn://example.com/read",
  "status": "approved",
  "api_product_list": "[implicit-test]",
  "api_product_list_json": ["implicit-test"],
  "expires_in": "1799", //--in seconds
  "developer.email": "joe@weathersample.com",
  "token_type": "BearerToken",
  "client_id": "U9AC66e9YFyI1yqaXgUF8H6b9wUN1TLk",
  "access_token": "TOKEN-1092837373654221",
  "organization_name": "wwitman",
  "refresh_token_expires_in": "0", //--in seconds
  "refresh_count": "0"
}

في هذه الحالة، يمكن للتطبيق إرسال طلب إلى خادم وكيل لواجهة برمجة تطبيقات مستضاف في Edge، ويحمل الحامل الرمز المميز TOKEN-1092837373654221، وEdge - عبر سياسة OAuthV2 التي تتضمن العملية = CheckAccessToken - سيتمكن من التحقّق من صحته. يمكنك تطبيق نمط استيراد مشابه رموز التفويض والرموز المميزة للتحديث.

لنتحدّث عن التحقّق من هوية العميل. المؤهلات

إن أحد المتطلبات الأساسية لإنشاء رمز مميز هو التحقق من صحة العميل الذي أرسل الطلب. بشكل افتراضي، تتحقق سياسة OAuthV2/GenerateAccessToken في Apigee Edge ضمنيًا من بيانات اعتماد العميل. في طلب الحصول على رمز OAuthV2 المميز عادةً، يتم تمرير client_id وclient_secret في عنوان التفويض، مُشفَّر عبر تفويض HTTP الأساسي (متسلسل منقوطة، ثم بترميز base64). تعمل سياسة OAuthV2/GenerateAccessToken في Apigee Edge على فك ترميز هذا العنوان البحث عن client_id والتحقق من أن client_secret الذي تم تمريره صالح لذلك client_id. وينجح هذا الأمر إذا كانت بيانات الاعتماد معروفة في Apigee Edge - أو بعبارةٍ أخرى، توجد تطبيق مطوِّر مُخزَّن في Apigee Edge ويحتوي على بيانات اعتماد تحتوي في حد ذاتها على معين client_id وclient_secret.

في حال عدم التحقّق من صحة بيانات اعتماد العميل باستخدام Apigee Edge، يجب: تصميم خادم وكيل واجهة برمجة التطبيقات، قبل أن يتم إنشاء رمز مميز، للتحقق من صحة بيانات العميل صراحةً من خلال بعض ووسائل أخرى. وغالبًا ما يكون ذلك من خلال سياسة ServiceCallout التي يتصل بنقطة نهاية بعيدة في شبكتك.

تحتاج بطريقة أو بأخرى، إما بشكل ضمني أو صريح، إلى التأكد من أن خادم وكيل واجهة برمجة التطبيقات تقوم بإنشاء رموز مميزة، تقوم أولاً بالتحقق من صحة بيانات اعتماد العميل. ضع في اعتبارك أن التحقق من صحة العميل مستقل عن إنشاء رمز الدخول. يمكنك ضبط Apigee Edge لتنفيذ الإجراءَين، أو تنفيذ أحدهما أو الآخر، أو عدم تنفيذ أي منهما.

إذا أردت أن يتم التحقق من هوية العميل في سياسة OAuthV2/GenerateAccessToken في Apigee Edge بيانات الاعتماد في متجر Edge، اضبط العنصر <ExternalAuthorization> على false داخل إعدادات السياسة، أو احذفها بالكامل. إذا كنت تريد استخدام خدمة المصادقة الخارجية للتحقق من صحة بيانات اعتماد العميل بشكل صريح، وتعيين <ExternalAuthorization> إلى true

على الرغم من أنّ Apigee Edge قد لا تتحقّق من صحة بيانات اعتماد العميل، لا يزال من الضروري التحقق من client_id إلى أن تكون معروفًا ومدارًا بواسطة Apigee Edge. كل access_token في Apigee Edge، سواء كان التي تم إنشاؤها باستخدام Apigee Edge أو التي تم إنشاؤها من خلال نظام خارجي ثم يتم استيرادها إلى Apigee Edge. يجب أن يكون مقترنًا بتطبيق عميل - ويشار إليه بواسطة client_id. لذلك حتى في حالة حيث لا يمكن لسياسة OAuthV2/GenerateAccessToken في Apigee Edge التحقق من صحة قيمة client_id و client_secret، ستتحقّق السياسة من أنّ client_id صالح ومتوفّر وليس إبطالها. لذا، كخطوة إعداد أساسية، قد تضطر إلى استيراد client_id's عبر Edge واجهة برمجة التطبيقات الإدارية.

مسار سياسة بروتوكول OAuth التابع لجهة خارجية في Apigee

لاستخدام الرموز المميزة من أنظمة OAuth التابعة لجهات خارجية في Apigee Edge، يجب إنشاء مسار إنشاء الوصول يجب أن تتبع الرموز المميزة أحد الأنماط التالية.

المصادر الخارجية التحقق من بيانات اعتماد العميل

  1. ServiceCallout للتحقق من بيانات اعتماد العميل الوارد، والحصول على رمز مميز خارجي.
  2. ExtractVariables أو خطوة JavaScript إلى استخراج الرمز المميّز الذي تم إنشاؤه خارجيًا من الردّ
  3. AssignMessage إلى وتعيين المتغير المعروف الخاص المسمى oauth_external_authorization_status. يجب أن تكون القيمة صحيحة للإشارة إلى أنّ بيانات اعتماد العميل صالحة.
  4. OAuthV2/GenerateAccessToken مع تم ضبط عنصر <ExternalAuthorization> على true وعنصر واحد على الأقل. من <ExternalAccessToken> أو <ExternalRefreshToken> أو <ExternalAuthorizationCode>

داخلي التحقق من بيانات اعتماد العميل

  • ServiceCallout الحصول على رمز مميّز خارجي.
  • ExtractVariables أو خطوة JavaScript إلى استخراج الرمز المميّز الذي تم إنشاؤه خارجيًا من الردّ
  • OAuthV2/GenerateAccessToken مع تم ضبط عنصر <ExternalAuthorization> على false وعنصر واحد على الأقل. من <ExternalAccessToken> أو <ExternalRefreshToken> أو <ExternalAuthorizationCode>

ملاحظات حول مسار ضبط السياسة

  • في حال أردت استخدام نظام خارجي للتحقق من صحة بيانات اعتماد العميل، لك تطوير مسار للسياسة يؤدي ما هو ضروري. عادةً ما تستخدم سياسة ServiceCallout لإرسال بيانات الاعتماد التي تم التعرف عليها خارجيًا إلى خدمة المصادقة. عادةً ما تعرض خدمة المصادقة الخارجية ردًا وإذا كانت بيانات الاعتماد صالحة، يتم أيضًا استخدام رمز دخول.

  • بعد ServiceCallout، يحتاج خادم وكيل واجهة برمجة التطبيقات إلى تحليل الرد لاستخراج وحالة الصلاحية، بالإضافة إلى access_token الذي تم إنشاؤه خارجيًا وربما refresh_token.

  • في سياسة OAuthV2/GenerateAccessToken، يمكنك ضبط العنصر <StoreToken>. على true، وضبط العنصر <ExternalAuthorization> على true أو false حسب الحاجة.

    عند تنفيذ سياسة OAuthV2/GenerateAccessToken، تتم قراءة المتغير oauth_external_authorization_status إذا تم تعيين المتغير وكانت القيمة true، فلن تحاول Apigee Edge التحقق من صحة بيانات اعتماد العميل. إذا كان المتغير لم يتم ضبطه أو كانت القيمة غير صحيحة، فسيحاول Apigee Edge التحقق من صحة بيانات العميل بيانات الاعتماد.

  • هناك ثلاثة عناصر لسياسة OAuthV2 تسمح لك بتحديد البيانات الخارجية. البيانات المراد استيرادها: <ExternalAccessToken>، <ExternalRefreshToken>, و<ExternalAuthorizationCode>. يقبل كل عنصر من هذه العناصر متغيّر التدفق. ستقرأ سياسة Edge هذا المتغير للعثور على رمز الدخول الذي تم إنشاؤه خارجيًا أو الرمز المميّز لإعادة التحميل أو رمز التفويض. الأمر متروك لك تطبيق السياسات والمنطق لوضع الرموز أو الرموز الخارجية في الترتيب المتغيرات.

    على سبيل المثال، تطلب التهيئة التالية في سياسة OAuthV2 من Edge البحث عن في متغير سياق باسم external_token.

    <ExternalAccessToken>external_token</ExternalAccessToken>

    كما ستحتاج أيضًا إلى خطوة سابقة تُعيِّن هذا المتغير.

  • بخصوص تعيين المتغير oauth_external_authorization_status، يعتبر المعامل المشترك أسلوب إعداد هذا المتغير هو استخدام سياسة AssignMessage مع عنصر assignVariable، كما يلي:

    <AssignMessage name="AssignMessage-SetVariable">
    <DisplayName>Assign Message - Set Variable</DisplayName>
    <AssignVariable>
        <Name>oauth_external_authorization_status</Name>
        <Value>true</Value>
    </AssignVariable>
    <IgnoreUnresolvedVariables>true</IgnoreUnresolvedVariables>
</AssignMessage>

    تذكَّر أنّ هذه السياسة يجب أن تقع قبل سياسة OAuthV2 التي تشير إلى العملية =. GenerateAccessToken.

مثال على سياسة OAuthV2

سياسة OAuthV2 التالية ينشئ رمز دخول إلى Apigee Edge وذلك في حال عثور Edge على رمز مميز في متغير التدفق external_access_token.

<OAuthV2 name="OAuth-v20-Store-External-Token">
    <ExternalAccessToken>external_access_token</ExternalAccessToken>
    <ExternalAuthorization>true</ExternalAuthorization>
    <Operation>GenerateAccessToken</Operation>
    <GenerateResponse enabled="true">
        <Format>FORM_PARAM</Format>
    </GenerateResponse>
    <ReuseRefreshToken>false</ReuseRefreshToken>
    <StoreToken>true</StoreToken>
    <SupportedGrantTypes>
        <GrantType>client_credentials</GrantType>
    </SupportedGrantTypes>
    <ExpiresIn ref='flow.variable'>2400000</ExpiresIn>
</OAuthV2>

نظريًا، يمكنك تطبيق هذا النمط مع أي تفويض OAuth2 تابع لجهة خارجية خدمة ما.