المصادقة والتفويض في التطبيق الخاص بك
يعد الأمان أمرا بالغ الأهمية لتطبيقات الويب الحديثة. إطار عمل Fluid، كجزء من بنية تطبيق الويب الخاص بك هو جزء مهم من البنية الأساسية لتأمينه. إطار عمل Fluid هو بنية ذات طبقات، ويتم تنفيذ المفاهيم المتعلقة بالمصادقة استنادا إلى خدمة Fluid التي تتصل بها. وهذا يعني أنه على الرغم من وجود نسق مصادقة شائعة عبر جميع خدمات Fluid، ستختلف التفاصيل والتفاصيل لكل خدمة.
خدمة Azure Fluid Relay
يتم تعيين معرف المستأجر ومفتاح سري للمستأجر الفريد لكل مستأجر خدمة Azure Fluid Relay تقوم بإنشائه.
المفتاح السري هو سر مشترك. يعرف التطبيق/الخدمة الخاصة بك ذلك، وتعرفه خدمة Azure Fluid Relay. نظرا لأن مفتاح سر المستأجر مرتبط بشكل فريد بالمستأجر الخاص بك، فاستخدمه لتوقيع ضمانات الطلبات إلى خدمة Azure Fluid Relay بأن الطلبات تأتي من مستخدم معتمد للمستأجر.
المفتاح السري هو كيف تعرف خدمة Azure Fluid Relay أن الطلبات تأتي من التطبيق أو الخدمة. هذا أمر بالغ الأهمية، لأنه بمجرد أن تثق خدمة Azure Fluid Relay في أن تطبيقك يقوم بالطلبات، يمكنه الوثوق بالبيانات التي ترسلها. هذا هو أيضا السبب في أنه من المهم أن يتم التعامل مع السر بشكل آمن.
تنبيه
يمكن لأي شخص لديه حق الوصول إلى السر انتحال صفة التطبيق الخاص بك عند الاتصال بخدمة Azure Fluid Relay.
JSON Web Tokens وخدمة Azure Fluid Relay
يستخدم Azure Fluid Relay رموز ويب JSON المميزة (JWTs) لترميز البيانات الموقعة باستخدام المفتاح السري والتحقق منها. رموز ويب JSON المميزة هي جزء موقع من JSON يمكن أن يتضمن معلومات إضافية حول الحقوق والأذونات.
إشعار
تفاصيل JWTs خارج نطاق هذه المقالة. لمزيد من المعلومات حول معيار JWT، راجع مقدمة إلى رموز ويب JSON المميزة.
على الرغم من أن تفاصيل المصادقة تختلف بين خدمات Fluid، يجب أن تكون العديد من القيم موجودة دائما.
- containerId تحتاج خدمة Fluid إلى معرف الحاوية لتحديد الخدمة التي تتوافق مع حاوية الاستدعاء. ملاحظة: يستدعي JWT معرف مستند الحقل هذا، ولكن تتوقع خدمة Fluid معرف حاوية في هذا الحقل.
- tenantId: تستخدم خدمة Azure Fluid Relay معرف المستأجر لاسترداد السر المشترك الذي ستستخدمه لمصادقة طلبك.
- النطاقات: تحدد النطاقات أذونات حاوية الاستدعاء. محتويات حقل النطاقات مرنة، مما يسمح لك بإنشاء أذونات مخصصة خاصة بك.
{
"alg": "HS256",
"typ": "JWT"
}.{
"documentId": "azureFluidDocumentId",
"scopes": [ "doc:read", "doc:write", "summary:write" ],
"user": {
"name": "TestUser",
"id": "Test-Id-123"
},
"iat": 1599098963,
"exp": 1599098963,
"tenantId": "AzureFluidTenantId",
"ver": "1.0"
}.[Signature]
يشير وضع المستخدم إلى ما إذا كان الاتصال في وضع القراءة أو القراءة/الكتابة. يمكن عرض هذا من الحقل في connectionsAzureAudience. يمكن تحديث أذونات نطاق الرمز المميز في دالة Azure بلا خادم ضمن الدالة generateToken .
const token = generateToken(
tenantId,
documentId,
key,
scopes ?? [ "Token Scope" ],
user
);
نطاقات الرمز المميز جنبا إلى جنب مع سلوك الحاوية والأوضاع كما يلي:
| نطاق الرمز المميز | سلوك المستند الخاص بي | سلوك مستند الجماعة المستهدفة |
|---|---|---|
| DocRead | القراءة والكتابة إلى المستند. لا تنعكس التغييرات التي تم إجراؤها على المستند في أي مستند جماعة مستهدفة آخر. الوضع: قراءة |
القراءة والكتابة إلى المستند. لا تنعكس التغييرات في أي مستند جماعة مستهدفة آخر. الوضع: الكتابة |
| DocWrite | القراءة والكتابة إلى المستند. تنعكس التغييرات التي تم إجراؤها في جميع مستندات الجمهور الأخرى. الوضع: الكتابة |
القراءة والكتابة إلى المستند. تنعكس التغييرات التي تم إجراؤها في جميع مستندات الجمهور الأخرى. الوضع: الكتابة |
| DocRead, DocWrite | القراءة والكتابة إلى المستند. تنعكس التغييرات التي تم إجراؤها في جميع مستندات الجمهور الأخرى. الوضع: الكتابة |
القراءة والكتابة إلى المستند. تنعكس التغييرات التي تم إجراؤها في جميع مستندات الجمهور الأخرى. الوضع: الكتابة |
إشعار
لاحظ أن الرمز المميز يتضمن أيضا معلومات المستخدم (راجع الأسطر 7-9 أعلاه). يمكنك استخدام هذا لزيادة معلومات المستخدم المتوفرة تلقائيا للتعليمات البرمجية Fluid باستخدام ميزة الجمهور . راجع إضافة بيانات مخصصة إلى الرموز المميزة لمزيد من المعلومات.
موفر الرمز المميز
يجب توقيع كل طلب إلى Azure Fluid Relay باستخدام JWT صالح. يفوض Fluid مسؤولية إنشاء هذه الرموز المميزة وتوقيعها لموفري الرموز المميزة.
موفر الرمز المميز مسؤول عن إنشاء وتوقيع الرموز المميزة @fluidframework/azure-client التي يستخدمها لتقديم طلبات إلى خدمة Azure Fluid Relay. يطلب منك توفير تنفيذ موفر الرمز المميز الآمن الخاص بك. ومع ذلك، يوفر InsecureTokenProvider Fluid الذي يقبل سر المستأجر الخاص بك، ثم ينشئ ويعيد رمزا مميزا موقعا محليا. موفر الرمز المميز هذا مفيد للاختبار، ولكن لا يمكن استخدامه في سيناريوهات الإنتاج.
موفر رمز مميز آمن بلا خادم
أحد الخيارات لإنشاء موفر رمز مميز آمن هو إنشاء وظيفة Azure بلا خادم وعرضها كموفر رمز مميز. يمكنك هذا من تخزين مفتاح سر المستأجر على خادم آمن. سيقوم تطبيقك بعد ذلك باستدعاء Azure Function لإنشاء رموز مميزة بدلا من توقيعها محليا كما InsecureTokenProvider يفعل. لمزيد من المعلومات، راجع كيفية: كتابة TokenProvider باستخدام Azure Function.
الاتصال مصادقة المستخدم إلى مصادقة خدمة Fluid
تقوم خدمات Fluid بمصادقة المكالمات الواردة باستخدام سر عميل مشترك، وهو غير مرتبط بمستخدم معين. يمكن إضافة مصادقة المستخدم استنادا إلى تفاصيل خدمة Fluid.
أحد الخيارات البسيطة لمصادقة المستخدم هو ببساطة استخدام Azure Function كموفر للرمز المميز الخاص بك، وفرض مصادقة المستخدم كشرط للحصول على رمز مميز. إذا حاول أحد التطبيقات استدعاء الدالة، فسيفشل ما لم تتم مصادقته مع نظام المصادقة الخاص بك. إذا كنت تستخدم معرف Microsoft Entra، على سبيل المثال، يمكنك إنشاء تطبيق Microsoft Entra ل Azure Function، وربطه بنظام المصادقة الخاص بمؤسستك.
في هذه الحالة، سيقوم المستخدم بتسجيل الدخول إلى التطبيق الخاص بك باستخدام معرف Microsoft Entra، والذي من خلاله ستحصل على رمز مميز لاستخدامه لاستدعاء دالة Azure. تعمل وظيفة Azure نفسها بنفس الطريقة، ولكنها الآن لا يمكن الوصول إليها إلا للأشخاص الذين قاموا أيضا بالمصادقة باستخدام معرف Microsoft Entra.
نظرا لأن Azure Function هي الآن نقطة الإدخال الخاصة بك في الحصول على رمز مميز صالح، فلن يتمكن سوى المستخدمين الذين قاموا بالمصادقة بشكل صحيح إلى الدالة من توفير هذا الرمز المميز لخدمة Azure Fluid Relay من تطبيق العميل الخاص بهم. يمكنك هذا النهج المكون من خطوتين من استخدام عملية المصادقة المخصصة الخاصة بك بالاقتران مع خدمة Azure Fluid Relay.