التحكم في الوصول إلى ناقل خدمة Microsoft Azure مع توقيعات الوصول المشتركة

مقالة
11/28/2023

تتناول هذه المقالة توقيعات الوصول المشترك (SAS) وكيفية عملها وكيفية استخدامها بطريقة غير محددة للنظام الأساسي مع ناقل خدمة Azure.

يحمي SAS الوصول إلى ناقل الخدمة استناداً إلى قواعد التخويل التي تم تكوينها إما على مساحة اسم أو كيان مراسلة (قائمة انتظار أو موضوع). قاعدة التخويل لها اسم، وترتبط بحقوق معينة، وتحمل زوجاً من مفاتيح التشفير. يمكنك استخدام اسم القاعدة والمفتاح عبر لناقل خدمة Microsoft Azure SDK أو في الكود الخاص بك لإنشاء رمز SAS المميز. يمكن للعميل بعد ذلك تمرير الرمز المميز إلى ناقل خدمة Microsoft Azure لإثبات التخويل للعملية المطلوبة.

إشعار

يدعم ناقل خدمة Azure تخويل الوصول إلى مساحة اسم ناقل خدمة Microsoft Azure والكيانات الخاصة به باستخدام معرف Microsoft Entra. يوفر تخويل المستخدمين أو التطبيقات باستخدام رمز OAuth 2.0 المميز الذي تم إرجاعه بواسطة معرف Microsoft Entra أمانا فائقا وسهولة استخدام عبر توقيعات الوصول المشترك (SAS). باستخدام معرف Microsoft Entra، ليست هناك حاجة لتخزين الرموز المميزة في التعليمات البرمجية الخاصة بك والمخاطرة بالثغرات الأمنية المحتملة.

توصي Microsoft باستخدام معرف Microsoft Entra مع تطبيقات ناقل خدمة Azure عندما يكون ذلك ممكنا. لمزيد من المعلومات، راجع المقالات التالية:

يمكنك تعطيل مصادقة المفتاح المحلي أو SAS لمساحة اسم ناقل خدمة Microsoft Azure والسماح بمصادقة Microsoft Entra فقط. للحصول على إرشادات خطوة بخطوة، راجع "Disable local authentication".

نظرة عامة على SAS

توقيعات الوصول المشتركة هي آلية مصادقة قائمة على المطالبات تستخدم رموزاً بسيطة. عند استخدام SAS، لا يتم تمرير المفاتيح على السلك. تُستخدم المفاتيح لتوقيع المعلومات بطريقة مشفرة والتي يمكن للخدمة التحقق منها لاحقاً. يمكن استخدام SAS بشكل مشابه لمخطط اسم المستخدم وكلمة المرور حيث يكون العميل في حيازة فورية لاسم قاعدة التخويل ومفتاح مطابق. يمكن أيضاً استخدام SAS بشكل مشابه لنموذج الأمان الموحد، حيث يتلقى العميل رمز وصول محدود زمنياً وموقعاً من خدمة رمز الأمان دون امتلاك مفتاح التوقيع.

يتم تكوين مصادقة SAS في ناقل خدمة Microsoft Azure مع نهج تخويل الوصول المشترك المسماة التي لها حقوق وصول مقترنة، وزوج من مفاتيح التشفير الأساسية والثانوية. المفاتيح هي قيم 256 بت في تمثيل Base 64. يمكنك تهيئة القواعد على مستوى مساحة الاسم، في قوائم انتظار ناقل خدمة Microsoft Azure والموضوعات.

إشعار

هذه المفاتيح هي سلاسل نص عادي باستخدام تمثيل Base 64، ويجب عدم فك ترميزها قبل استخدامها.

يحتوي الرمز المميز لتوقيع الوصول المشترك على اسم نهج التخويل المختار، وURI للمورد الذي يجب الوصول إليه، ووقت انتهاء الصلاحية، وتوقيع التشفير HMAC-SHA256 المحسوب على هذه الحقول باستخدام إما مفتاح التشفير الأساسي أو الثانوي الخاص بقاعدة التخويل المختارة.

نُهج ترخيص الوصول المشترك

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

لكل قاعدة نهج ترخيص، يمكنك تحديد ثلاث أجزاء من المعلومات: الاسم والنطاق والحقوق. الاسم هو فقط؛ اسم فريد ضمن هذا النطاق. النطاق سهل بما فيه الكفاية: إنه عنوان URI للمورد المقصود. بالنسبة لمساحة اسم ناقل خدمة Microsoft Azure، يكون النطاق هو مساحة الاسم المؤهلة بالكامل، مثل https://<yournamespace>.servicebus.windows.net/.

يمكن أن تكون الحقوق التي توفرها قاعدة النهج مزيجاً مما يلي:

إرسال - يمنح الحق في إرسال رسائل إلى الكيان
الاستماع - يمنح الحق في تلقي (قائمة الانتظار والاشتراكات) وجميع معالجة الرسائل ذات الصلة
إدارة - يمنح الحق في إدارة تخطيط الشبكة لمساحة الاسم، بما في ذلك إنشاء الكيانات وحذفها

يتضمن حق الإدارة حقوق الإرسال والاستماع.

يمكن أن تحتوي مساحة الاسم أو نهج الكيان على ما يصل إلى 12 قاعدة لتخويل الوصول المشترك، ما يوفر مساحة لثلاث مجموعات من القواعد، كل منها يغطي الحقوق الأساسية، ومجموعة الإرسال والاستماع. هذا الحد لكل كيان، مما يعني مساحة الاسم وكل كيان يمكن أن يكون لديه ما يصل إلى 12 قاعدة تخويل وصول مشترك. يؤكد هذا الحد على أن متجر نهج SAS لا يُقصد به أن يكون مستخدماً أو متجراً لحساب الخدمة. إذا احتاج تطبيقك إلى منح الوصول إلى ناقل خدمة Microsoft Azure استناداً إلى هويات المستخدم أو الخدمة، فيجب عليه تنفيذ خدمة رمز الأمان التي تصدر رموز SAS بعد التحقق من المصادقة والوصول.

يتم تعيين مفتاح أساسي ومفتاح ثانوي لقاعدة التخويل. هذه المفاتيح هي مفاتيح قوية من ناحية التشفير. لا تفقدها أو تسربها - ستكون متاحة دائماً في مدخل Microsoft Azure. يمكنك استخدام أي من المفاتيح التي تم إنشاؤها، ويمكنك إعادة إنشائها في أي وقت. إذا قمت بإعادة إنشاء مفتاح أو تغييره في النهج، فإن جميع الرموز المميزة التي تم إصدارها مسبقاً بناءً على هذا المفتاح تصبح غير صالحة على الفور. ومع ذلك، تستمر الاتصالات المستمرة التي تم إنشاؤها استنادا إلى هذه الرموز المميزة في العمل حتى تنتهي صلاحية الرمز المميز.

عند إنشاء مساحة اسم ناقل خدمة Microsoft Azure، يتم تلقائياً إنشاء قاعدة نهج تسمى RootManageSharedAccessKey لمساحة الاسم. تحتوي هذه النهج على أذونات إدارة لمساحة اسم الخدمة بالكامل. يوصى بمعاملة هذه القاعدة كحساب جذر إداري وعدم استخدامها في تطبيقك. يمكنك إنشاء المزيد من قواعد النهج في علامة التبويب Shared access policies لمساحة الاسم في المدخل، عبر PowerShell أو Azure CLI.

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

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

أفضل الممارسات عند استخدام توقيعات الوصول المشترك

عند استخدام توقيعات الوصول المشتركة (SAS) في تطبيقاتك، يجب أن تكون على دراية باحتمال وقوع خطرين:

إذا تم تسريب SAS، فيمكن استخدامه من قبل أي شخص يحصل عليه، ما قد يعرض موارد خدمة ناقل خدمة Microsoft Azure الخاصة بك للخطر.
إذا انتهت صلاحية SAS المقدمة إلى تطبيق عميل ولم يتمكن التطبيق من استرداد SAS جديد من الخدمة الخاصة بك، فقد يتم إعاقة وظيفة التطبيق.

يمكن أن تساعد التوصيات التالية لاستخدام توقيعات الوصول المشترك في التخفيف من هذه المخاطر:

اطلب من العملاء تجديد SAS تلقائياً إذا لزم الأمر: يجب على العملاء تجديد SAS قبل انتهاء الصلاحية بوقت طويل، لإتاحة الوقت لإعادة المحاولة إذا كانت الخدمة التي توفر خدمة SAS غير متوفرة. إذا كان من المفترض استخدام SAS الخاص بك لعدد قليل من العمليات الفورية قصيرة الأجل المتوقع إكمالها خلال فترة انتهاء الصلاحية، فقد يكون غير ضروري لأنه لا يتوقع تجديد SAS. ومع ذلك، إذا كان لديك عميل يقوم بشكل روتيني بتقديم طلبات عبر SAS، فإن إمكانية انتهاء الصلاحية تدخل حيز التنفيذ. الاعتبار الرئيسي هو الموازنة بين الحاجة إلى أن تكون SAS قصيرة الأجل (كما ذكر سابقاً) والحاجة إلى التأكد من أن العميل يطلب التجديد في وقت مبكر بما فيه الكفاية (لتجنب الانقطاع بسبب انتهاء صلاحية SAS قبل التجديد الناجح).
كن حذرا مع وقت بدء SAS: إذا قمت بتعيين وقت البدء ل SAS إلى الآن، ثم بسبب انحراف الساعة (الاختلافات في الوقت الحالي وفقا لأجهزة مختلفة)، فقد ترى حالات فشل على فترات متقطعة للدقائق القليلة الأولى. بشكل عام، عيِّن وقت البدء ليكون 15 دقيقة على الأقل في الماضي. أو لا تقم بتعيينه على الإطلاق، ما يجعله صالحاً على الفور في جميع الحالات. ينطبق الشيء نفسه عموماً على وقت انتهاء الصلاحية أيضاً. تذكر أنك قد تلاحظ ما يصل إلى 15 دقيقة من انحراف الساعة في أي اتجاه بناء على أي طلب.
كن محدداً بشأن المورد الذي سيتم الوصول إليه: أفضل ممارسة للأمان هي تزويد المستخدم بالحد الأدنى من الامتيازات المطلوبة. إذا كان المستخدم لا يحتاج إلا إلى حق الوصول للقراءة فقط إلى كيان واحد، فامنحه حق الوصول للقراءة فقط إلى ذلك الكيان، وليس حق الوصول للقراءة/الكتابة/الحذف إلى جميع الكيانات. كما أنه يساعد في تقليل الضرر إذا تم اختراق SAS لأن SAS لديه قوة أقل في يد المهاجم.
لا تستخدم دائماً SAS: في بعض الأحيان، تفوق المخاطر المرتبطة بعملية معينة ضد ناقل الخدمة فوائد SAS. لمثل هذه العمليات، أنشئ خدمة من المستوى المتوسط تكتب إلى ناقل الخدمة بعد التحقق من صحة قاعدة العمل، والمصادقة، والتدقيق.
استخدم دائماً HTTPs: استخدم دائماً Https لإنشاء أو توزيع SAS. إذا تم تمرير SAS عبر HTTP وتم اعتراضه، فإن المهاجم الذي يقوم بإرفاق هجوم اختراق وسيط يكون قادراً على قراءة SAS ثم استخدامه تماماً كما يمكن للمستخدم المقصود، مما قد يؤدي إلى اختراق البيانات الحساسة أو السماح بتلف البيانات عن طريق المستخدم الضار.

التكوين لمصادقة توقيع الوصول المشترك

يمكنك تكوين نهج تخويل الوصول المشترك على مساحات أسماء ناقل خدمة Microsoft Azure أو قوائم الانتظار أو الموضوعات. تكوينه على اشتراك ناقل خدمة Microsoft Azure غير مدعوم حالياً، ولكن يمكنك استخدام القواعد المكونة على مساحة اسم أو موضوع لتأمين الوصول إلى الاشتراكات.

Diagram that shows an example namespace with a few authorization rules.

في هذا الشكل، تنطبق قواعد التخويل managerRuleNS، وsendRuleNS، وlistenRuleNS على كلٍ من قائمة الانتظار Q1 والموضوع T1، بينما تنطبق قواعد listenRuleQ وsendRuleQ فقط على قائمة الانتظار Q1 وقاعدة sendRuleT تنطبق فقط على الموضوع T1.

إنشاء رمز مميز توقيع الوصول المشترك

يمكن لأي عميل لديه حق الوصول إلى اسم قاعدة التخويل وأحد مفاتيح التوقيع الخاصة به إنشاء رمز SAS المميز. يتم إنشاء الرمز المميز بواسطة صياغة سلسلة بالتنسيق التالي:

SharedAccessSignature sig=<signature-string>&se=<expiry>&skn=<keyName>&sr=<URL-encoded-resourceURI>

se – لحظة انتهاء صلاحية الرمز المميز. عدد صحيح يعكس الثواني منذ العصر 00:00:00 UTC في 1 يناير 1970 (حقبة UNIX) عند انتهاء صلاحية الرمز المميز.
skn - اسم قاعدة التخويل.
sr - عنوان URL المشفر بعنوان URL للمورد الذي يتم الوصول إليه.
sig - توقيع HMACSHA256 بترميز URL. يبدو حساب التجزئة مشابهاً للشفرة الزائفة التالية وإرجاع base64 من الإخراج الثنائي البسيط.
```
urlencode(base64(hmacsha256(urlencode('https://<yournamespace>.servicebus.windows.net/') + "\n" + '<expiry instant>', '<signing key>')))
```

هام

للحصول على أمثلة حول إنشاء رمز SAS المميز باستخدام لغات برمجة مختلفة، راجع Generate SAS token.

يحتوي الرمز المميز على القيم غير المجزأة بحيث يمكن للمستلم إعادة حساب التجزئة باستخدام نفس المعلمات، للتحقق من أن المُصدر يمتلك مفتاح توقيع صالح.

المورد URI هو URI الكامل لمورد ناقل خدمة Microsoft Azure الذي يُطلب الوصول إليه. على سبيل المثال: http://<namespace>.servicebus.windows.net/<entityPath>،sb://<namespace>.servicebus.windows.net/<entityPath>، أو http://contoso.servicebus.windows.net/contosoTopics/T1/Subscriptions/S3.

يجب أن يكون عنوان URI مشفرة بنسبة مئوية.

يجب تكوين قاعدة تخويل الوصول المشترك المستخدمة للتوقيع على الكيان المحدد بواسطة URI هذا، أو بواسطة أحد الأصول الهرمية. على سبيل المثال، http://contoso.servicebus.windows.net/contosoTopics/T1 أو http://contoso.servicebus.windows.net في المثال السابق.

رمز SAS المميز صالح لجميع الموارد مسبوقة بـ <resourceURI>المستخدمة فيsignature-string.

تجديد المفاتيح

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

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

لإعادة إنشاء المفاتيح الأساسية والثانوية في مدخل Azure، اتبع الخطوات التالية:

انتقل إلى مساحة اسم Service Bus في مدخل Azure.
حدد "Shared Access Policies" من القائمة اليسرى.
حدد السياسة من القائمة. في المثال التالي، يتم تحديد RootManageSharedAccessKey.
لإعادة إنشاء المفتاح الأساسي، في صفحة نهج SAS: RootManageSharedAccessKey ، حدد إعادة إنشاء المفتاح الأساسي على شريط الأوامر.
لإعادة إنشاء المفتاح الثانوي، في صفحة نهج SAS: RootManageSharedAccessKey ، حدد ... من شريط الأوامر، ثم حدد إعادة إنشاء المفتاح الثانوي.

إذا كنت تستخدم Azure PowerShell، فاستخدم New-AzServiceBusKey cmdlet لإعادة إنشاء المفاتيح الأساسية والثانوية لمساحة اسم ناقل خدمة Microsoft Azure. يمكنك أيضاً تحديد قيم للمفاتيح الأساسية والثانوية التي يتم إنشاؤها، باستخدام المعلمة -KeyValue.

إذا كنت تستخدم Azure CLI، فاستخدم az servicebus namespace authorization-rule keys renew الأمر لإعادة إنشاء المفاتيح الأساسية والثانوية لمساحة اسم ناقل خدمة Microsoft Azure. يمكنك أيضاً تحديد قيم للمفاتيح الأساسية والثانوية التي يتم إنشاؤها، باستخدام المعلمة --key-value.

مصادقة توقيع الوصول المشترك باستخدام ناقل خدمة Microsoft Azure

يتضمن السيناريو الموضح على النحو التالي تكوين قواعد التخويل وإنشاء رموز SAS المميزة وتخويل العميل.

للحصول على عينة من تطبيق ناقل خدمة Microsoft Azure الذي يوضح التكوين ويستخدم تخويل SAS، راجع Shared Access Signature authentication with Service Bus.

الوصول إلى قواعد تخويل الوصول المشترك في أحد الكيانات

استخدم عملية الحصول/ التحديث على قوائم الانتظار أو الموضوعات في مكتبات الإدارة لناقل خدمة Microsoft Azure للوصول إلى/ تحديث قواعد ترخيص الوصول المشترك المقابلة. يمكنك أيضاً إضافة القواعد عند إنشاء قوائم الانتظار أو الموضوعات باستخدام هذه المكتبات.

استخدام تخويل توقيع الوصول المشترك

يمكن للتطبيقات التي تستخدم أي من SDK لناقل خدمة Microsoft Azure بأي من اللغات المدعومة رسميا مثل .NET وJava وJavaScript وPython الاستفادة من تخويل SAS من خلال سلسلة الاتصال التي تم تمريرها إلى منشئ العميل.

يمكن أن تتضمن سلاسل الاتصال اسم قاعدة(SharedAccessKeyName)ومفتاح قاعدة(SharedAccessKey)أو رمز مميز تم إصداره مسبقاً (SharedAccessSignature). عندما تكون هذه موجودة في سلسلة الاتصال التي تم تمريرها إلى أي مُنشئ أو طريقة مصنع تقبل سلسلة اتصال، يتم إنشاء موفر رمز SAS وتعبئته تلقائياً.

لاستخدام ترخيص SAS مع اشتراكات ناقل خدمة Microsoft Azure، يمكنك استخدام مفاتيح SAS التي تم تكوينها في مساحة اسم ناقل خدمة Microsoft Azure أو على أحد الموضوعات.

استخدم توقيع الوصول المشترك (على مستوى HTTP)

الآن بعد أن عرفت كيفية إنشاء توقيعات الوصول المشتركة لأي كيانات في ناقل الخدمة، أنت جاهز لإجراء نشر HTTP:

POST https://<yournamespace>.servicebus.windows.net/<yourentity>/messages
Content-Type: application/json
Authorization: SharedAccessSignature sr=https%3A%2F%2F<yournamespace>.servicebus.windows.net%2F<yourentity>&sig=<yoursignature from code above>&se=1438205742&skn=KeyName
ContentType: application/atom+xml;type=entry;charset=utf-8

تذكر، هذا يلائم كل شيء. يمكنك إنشاء SAS لقائمة انتظار أو موضوع أو اشتراك.

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

استخدم توقيع الوصول المشترك (على مستوى AMQP)

في القسم السابق، رأيت كيفية استخدام رمز SAS المميز مع طلب نشر HTTP لإرسال البيانات إلى ناقل خدمة Microsoft Azure. كما تعلم، يمكنك الوصول إلى ناقل خدمة Microsoft Azure باستخدام بروتوكول وضع الرسائل في قائمة انتظار (AMQP) وهو البروتوكول المفضل للاستخدام لأسباب تتعلق بالأداء، في العديد من السيناريوهات. تم وصف استخدام رمز SAS المميز مع AMQP في المستند AMQP Claim-Based Security Version 1.0 الموجود في مسودة العمل منذ 2013 ولكنه مدعوم من Azure اليوم.

قبل البدء في إرسال البيانات إلى ناقل خدمة Microsoft Azure، يجب على الناشر إرسال رمز SAS المميز داخل رسالة AMQP إلى عقدة AMQP محددة جيداً باسم $ cbs (يمكنك رؤيتها كقائمة انتظار "خاصة" تستخدمها خدمة الحصول على جميع الرموز SAS المميزة والتحقق من صحتها). يجب على الناشر تحديد حقل ReplyTo داخل رسالة AMQP؛ هذه هي العقدة التي ترد فيها الخدمة على الناشر بنتيجة التحقق من صحة الرمز المميز (نموذج طلب/رد بسيط بين الناشر والخدمة). يتم إنشاء عقدة الرد هذه "بشكل فوري"، وهي تتحدث عن "الإنشاء الديناميكي للعقدة البعيدة" كما هو موضح في مواصفات AMQP 1.0. بعد التحقق من صلاحية رمز SAS المميز، يمكن للناشر المضي قدماً والبدء في إرسال البيانات إلى الخدمة.

توضح الخطوات التالية كيفية إرسال رمز SAS المميز باستخدام بروتوكول AMQP باستخدام مكتبة AMQP.NET Lite. من المفيد إذا لم تتمكن من استخدام SDK لناقل خدمة Microsoft Azure الرسمي (على سبيل المثال، على WinRT و.NET Compact Framework و.NET Micro Framework و Mono) التي تم تطويرها في C#. وهذه المكتبة مفيدة للمساعدة في فهم كيفية عمل الأمان المستند إلى المطالبات على مستوى AMQP، كما رأيت كيف يعمل على مستوى HTTP (مع طلب نشر HTTP ورمز SAS المميز الذي تم إرساله داخل رأس "التخويل"). إذا لم تكن بحاجة إلى مثل هذه المعرفة العميقة حول AMQP، يمكنك استخدام Service Bus SDK الرسمية بأي من اللغات المدعومة مثل .NET وJava وJavaScript وPython وGo، والتي ستقوم بذلك نيابة عنك.

C#‎

/// <summary>
/// Send claim-based security (CBS) token
/// </summary>
/// <param name="shareAccessSignature">Shared access signature (token) to send</param>
private bool PutCbsToken(Connection connection, string sasToken)
{
    bool result = true;
    Session session = new Session(connection);

    string cbsClientAddress = "cbs-client-reply-to";
    var cbsSender = new SenderLink(session, "cbs-sender", "$cbs");
    var cbsReceiver = new ReceiverLink(session, cbsClientAddress, "$cbs");

    // construct the put-token message
    var request = new Message(sasToken);
    request.Properties = new Properties();
    request.Properties.MessageId = Guid.NewGuid().ToString();
    request.Properties.ReplyTo = cbsClientAddress;
    request.ApplicationProperties = new ApplicationProperties();
    request.ApplicationProperties["operation"] = "put-token";
    request.ApplicationProperties["type"] = "servicebus.windows.net:sastoken";
    request.ApplicationProperties["name"] = Fx.Format("amqp://{0}/{1}", sbNamespace, entity);
    cbsSender.Send(request);

    // receive the response
    var response = cbsReceiver.Receive();
    if (response == null || response.Properties == null || response.ApplicationProperties == null)
    {
        result = false;
    }
    else
    {
        int statusCode = (int)response.ApplicationProperties["status-code"];
        if (statusCode != (int)HttpStatusCode.Accepted && statusCode != (int)HttpStatusCode.OK)
        {
            result = false;
        }
    }

    // the sender/receiver might be kept open for refreshing tokens
    cbsSender.Close();
    cbsReceiver.Close();
    session.Close();

    return result;
}

يتلقى الأسلوب PutCbsToken()الاتصال (مثيل فئة اتصال AMQP كما هو منصوص عليه في مكتبة AMQP .NET Lite) الذي يمثل اتصال TCP بالخدمة والمعلمة sasToken وهي رمز SAS المميز لإرسالها.

إشعار

من المهم أن يتم إنشاء الاتصال من خلال تعيين آلية مصادقة SASL على ANONYMOUS (وليس PLAIN الافتراضي مع اسم المستخدم وكلمة المرور المستخدمين عندما لا تحتاج إلى إرسال رمز SAS المميز).

بعد ذلك، ينشئ الناشر رابطي AMQP لإرسال رمز SAS المميز وتلقي الرد (نتيجة التحقق من صحة الرمز المميز) من الخدمة.

تحتوي رسالة AMQP على مجموعة من الخصائص ومعلومات أكثر من رسالة بسيطة. رمز SAS المميز عبارة عن نص الرسالة (باستخدام مُنشئها). تم تعيين الخاصية "ReplyTo" على اسم العقدة لتلقي نتيجة التحقق من الصحة على ارتباط المتلقي (يمكنك تغيير اسمها إذا أردت، وسيتم إنشاؤها ديناميكياً بواسطة الخدمة). تستخدم الخدمة آخر ثلاث خصائص تطبيق/ مخصصة للإشارة إلى نوع العملية التي يتعين عليها تنفيذها. كما هو موضح في مسودة مواصفات CBS، يجب أن تكون اسم العملية ("وضع الرمز المميز")، ونوع الرمز المميز(في هذه الحالة، servicebus.windows.net:sastoken)، و"اسم" الجمهور الذي ينطبق عليه الرمز المميز (الكيان بأكمله).

بعد إرسال الناشر رمز SAS على رابط المرسل، يجب على الناشر قراءة الرد على رابط المستلم. الرد عبارة عن رسالة AMQP بسيطة مع خاصية تطبيق تسمى "status-code" والتي يمكن أن تحتوي على نفس القيم مثل رمز حالة HTTP.

الحقوق المطلوبة لعمليات ناقل خدمة Microsoft Azure

يوضح الجدول التالي حقوق الوصول المطلوبة للعمليات المختلفة على موارد ناقل خدمة Microsoft Azure.

العملية	المطالبة المرغوبة	نطاق المطالبة
مساحه الاسم
تكوين قاعدة التخويل على مساحة الاسم	إدارة	أي عنوان لمساحة الاسم
سجل الخدمة
تعداد النُهج خاصة	إدارة	أي عنوان لمساحة الاسم
بدء الاستماع على مساحة اسم	الإصغاء	أي عنوان لمساحة الاسم
إرسال رسائل إلى مستمع في مساحة اسم	إرسال	أي عنوان لمساحة الاسم
الصف
إنشاء ‏‫‏‏قائمة انتظار‬	إدارة	أي عنوان لمساحة الاسم
حذف قائمة انتظار	إدارة	أي عنوان قائمة انتظار صالح
تعداد قوائم الانتظار	إدارة	/$ الموارد/قوائم الانتظار
الحصول على وصف قائمة الانتظار	إدارة	أي عنوان قائمة انتظار صالح
تكوين قاعدة التفويض لقائمة انتظار	إدارة	أي عنوان قائمة انتظار صالح
إرسال إلى قائمة الانتظار	إرسال	أي عنوان قائمة انتظار صالح
استقبال الرسائل من قائمة الانتظار	الإصغاء	أي عنوان قائمة انتظار صالح
التخلي عن الرسائل أو إكمالها بعد تلقيها في وضع peek-lock	الإصغاء	أي عنوان قائمة انتظار صالح
تأجيل رسالة لاستردادها لاحقاً	الإصغاء	أي عنوان قائمة انتظار صالح
إرسال رسالة مرتدة	الإصغاء	أي عنوان قائمة انتظار صالح
الحصول على الحالة المرتبطة بجلسة انتظار الرسائل	الإصغاء	أي عنوان قائمة انتظار صالح
الحصول على الحالة المرتبطة بجلسة انتظار الرسائل	الإصغاء	أي عنوان قائمة انتظار صالح
جدولة رسالة لتسليمها في وقت لاحق	الإصغاء	أي عنوان قائمة انتظار صالح
الموضوع
إنشاء موضوع	إدارة	أي عنوان لمساحة الاسم
حذف موضوع	إدارة	أي عنوان موضوع صالح
تعداد المواضيع	إدارة	/$الموارد/المواضيع
الحصول على وصف الموضوع	إدارة	أي عنوان موضوع صالح
تكوين قاعدة التخويل لموضوع	إدارة	أي عنوان موضوع صالح
إرسال إلى الموضوع	إرسال	أي عنوان موضوع صالح
الاشتراك
إنشاء اشتراك	إدارة	أي عنوان لمساحة الاسم
حذف الاشتراك	إدارة	../الموضوع الخاص بي/الاشتراكات/الاشتراك الخاص بي
تعداد الاشتراكات	إدارة	../الموضوع الخاص بي/الاشتراكات
الحصول على وصف الاشتراك	إدارة	../الموضوع الخاص بي/الاشتراكات/الاشتراك الخاص بي
التخلي عن الرسائل أو إكمالها بعد تلقيها في وضع peek-lock	الإصغاء	../الموضوع الخاص بي/الاشتراكات/الاشتراك الخاص بي
تأجيل رسالة لاستردادها لاحقاً	الإصغاء	../الموضوع الخاص بي/الاشتراكات/الاشتراك الخاص بي
إرسال رسالة مرتدة	الإصغاء	../الموضوع الخاص بي/الاشتراكات/الاشتراك الخاص بي
الحصول على الحالة المقترنة بجلسة موضوع	الإصغاء	../الموضوع الخاص بي/الاشتراكات/الاشتراك الخاص بي
الحصول على الحالة المقترنة بجلسة موضوع	الإصغاء	../الموضوع الخاص بي/الاشتراكات/الاشتراك الخاص بي
القواعد
إنشاء قاعدة	الإصغاء	../الموضوع الخاص بي/الاشتراكات/الاشتراك الخاص بي
حذف قاعدة	الإصغاء	../الموضوع الخاص بي/الاشتراكات/الاشتراك الخاص بي
تعداد القواعد	الإدارة أو الاستماع	../الموضوع الخاص بي/الاشتراكات/الاشتراك الخاص بي/القواعد

الخطوات التالية

لمعرفة المزيد حول رسائل ناقل خدمة Microsoft Azure، راجع الموضوعات التالية.

التحكم في الوصول إلى ناقل خدمة Microsoft Azure مع توقيعات الوصول المشتركة

نظرة عامة على SAS

نُهج ترخيص الوصول المشترك

أفضل الممارسات عند استخدام توقيعات الوصول المشترك

التكوين لمصادقة توقيع الوصول المشترك

إنشاء رمز مميز توقيع الوصول المشترك

تجديد المفاتيح

مصادقة توقيع الوصول المشترك باستخدام ناقل خدمة Microsoft Azure

الوصول إلى قواعد تخويل الوصول المشترك في أحد الكيانات

استخدام تخويل توقيع الوصول المشترك

استخدم توقيع الوصول المشترك (على مستوى HTTP)

استخدم توقيع الوصول المشترك (على مستوى AMQP)

C#‎

الحقوق المطلوبة لعمليات ناقل خدمة Microsoft Azure

الخطوات التالية

الموارد الإضافية