تمكين عملك: ربط أدوات AI بخدمتك القائمة مع التحكم في الوصول
تعلم كيفية تمكين عملك عن طريق ربط أدوات AI بخدماتك الحالية بأمان باستخدام الرموز الشخصية للوصول وبروتوكول سياق النموذج (MCP)، مع شفرات مصدر كاملة وأمثلة عملية.
تعلم كيفية تمكين عملك عن طريق ربط أدوات AI بخدماتك الحالية بأمان باستخدام الرموز الشخصية للوصول وبروتوكول سياق النموذج (MCP)، مع شفرات مصدر كاملة وأمثلة عملية.
مرحبًا بكم في الدليل حول ربط أدوات AI بخدماتك الحالية مع التحكم في الوصول!
سنستكشف كيفية تجهيز خدماتك الحالية لأدوات AI، خاصة من خلال التكامل مع LLM (باستخدام بروتوكول سياق النموذج)) ووكلاء AI مختلفين، مع معالجة تحديات التحكم في الوصول.
من خلال هذا الدليل، ستكتسب:
نحن نوفر موارد كاملة للتعليمات البرمجية، مشروع تجريبي مكتمل شفرات المصدر (واجهات أمامية وخلفية وخادم MCP مضمنة)، وحتى أدلة عملية لمساعدتك في بناء خدمات جاهزة لل AI من البداية.
إليك كيف يمكن لهذا الدليل تحسين عملك:
لنبدأ!
MCP (بروتوكول سياق النموذج) هو بروتوكول مفتوح وشامل يوضح كيفية تقديم التطبيقات لمعلومات السياق إلى النماذج اللغوية الكبيرة (LLMs).
يتكون MCP من عدة مكونات رئيسية تعمل معًا لتمكين أدوات AI من الوصول إلى خدماتك:
في هذا الدليل، تحتاج فقط إلى معرفة أن خادم MCP هو نقطة الاتصال الرئيسية بين خدمتك وأدوات AI. إنه مسؤول عن توفير سلسلة من الأدوات لاستخدام LLM، وهذه الأدوات ستتفاعل مع خدماتك الخاصة. لمزيد من التفاصيل حول MCP، يمكنك الرجوع إلى ما هو MCP (بروتوكول سياق النموذج) وكيف يعمل. هنا، سنركز فقط على خادم MCP.
سنستخدم نظام إدارة المحتوى (CMS) الذي يتضمن سياسات التحكم في الوصول بناءً على الأدوار (RBAC) كمثال لنا. سننشئ خادم MCP له ونحدد أداة get-available-article-count التي تتيح لـ LLM استرجاع عدد المقالات المتاحة للمستخدم الحالي في CMS:
هذه هي الشفرة الأساسية لربط خادم MCP بخدمتك. في تنفيذ هذه الأداة، يرسل طلبًا إلى نقطة نهاية api/articles للخدمة ويعيد النتيجة.
ومع ذلك، هذا بعيد عن الكفاية، لأن API لخدمتك قد لا تكون عامة. تحتاج كل نقطة نهاية إلى التحكم في الوصول، ويمكن للمستخدمين المختلفين الوصول إلى موارد وبيانات مختلفة.
لذلك، سنتحدث بعد ذلك عن كيفية إضافة التحكم في الوصول إلى خدمتك.
من المهم أن نفهم أن المستخدمين الذين يصلون إلى نظامك عبر أدوات AI هم نفس الأفراد الذين قد يستخدمون نظامك مباشرة - يعمل خادم MCP كممثل لهم عندما يتفاعلون عبر أدوات AI.
لذا عندما يصل المستخدمون إلى خدماتك من خلال أدوات AI، تنشأ تحديان عمليان للتحكم في الوصول:
المفتاح لحل هذه المشاكل هو:
كيف يمكن للمستخدمين السماح لخادم MCP بمنح الوصول من خدمتك دون استخدام بيانات اعتمادهم وتسجيل الدخول التفاعلي؟
إذا تمكنت من حل هذه المشكلة، يمكنك التفاعل مباشرة مع خدمتك عبر خادم MCP، ويمكن لخدمتك الاستمرار في استخدام آلية التحكم في الوصول المصممة مسبقًا للمستخدمين، دون الحاجة إلى إعادة تصميم نظام جديد فقط لخادم MCP!
لكن هل هذا ممكن؟
بالطبع هو كذلك! يمكننا حل هذه المشكلة بشكل مثالي باستخدام الرموز الشخصية للوصول!
توفر الرموز الشخصية للوصول (PATs) وسيلة آمنة للمستخدمين لمنح رمز وصول دون استخدام بيانات اعتمادهم وتسجيل الدخول التفاعلي. هذا مفيد لـ CI/CD، والبرامج النصية، أو التطبيقات التي تحتاج إلى الوصول إلى الموارد برمجيًا.
إليك كيف تبدو سير العمل:
لذا، طالما يدعم نظامك الرموز الشخصية للوصول (PAT)، يمكنك حل تحديات التحكم في الوصول بين أدوات AI وخدماتك الحالية دون إعادة تصميم آليات المصادقة الخاصة بك، مع ضمان أمان البيانات وحماية الخصوصية لمستخدميك.
الآن، دعونا نرى كيف نطبق ذلك عمليًا.
في هذا القسم، سنقوم بتطبيق التحكم في الوصول لخادم MCP باستخدام نظام CMS الحالي كنظامنا الأساسي.
يمكنك الاطلاع على دورة CMS كاملة التعليمات البرمجية ومصدر الشفرة في RBAC عند الممارسة: تنفيذ التفويض الآمن لتطبيقك، ولكن هذا ليس إلزاميًا، سنتناول جميع المبادئ الأساسية هنا.
نظام CMS مستند إلى Logto، منصة هوية مفتوحة المصدر شهيرة توفر حلاً شاملًا للمصادقة والتفويض، ولكن التنفيذ التقني ليس محور هذه المقالة.
الخطوة الأولى في تنفيذ التحكم في الوصول هي تصميم الأذونات وسياسات التحكم في الوصول لنظامك.
في مثال CMS الخاص بنا، قمنا بتصميم نقاط نهاية API التالية استنادًا إلى RBAC (التحكم في الوصول بناءً على الأدوار) وحددنا الأذونات المطلوبة للوصول إلى كل نقطة نهاية:
| النقطة النهائية | منطق التحكم في الوصول |
|---|---|
| GET /api/articles | - أي شخص لديه إذن list:articles، أو المؤلفين يمكن أن يروا مقالاتهم الخاصة |
| GET /api/articles/:id | - أي شخص لديه إذن read:articles، أو مؤلف المقال |
| POST /api/articles | - أي شخص لديه إذن create:articles |
| PATCH /api/articles/:id | - أي شخص لديه إذن update:articles، أو مؤلف المقال |
| DELETE /api/articles/:id | - أي شخص لديه إذن delete:articles، أو مؤلف المقال |
| PATCH /api/articles/:id/published | - فقط المستخدمين لديهم إذن publish:articles |
تصميم الأذونات للنظام كما يلي:
| الإذن | الوصف |
|---|---|
| list:articles | عرض قائمة جميع المقالات في النظام |
| read:articles | قراءة المحتوى الكامل لأي مقال |
| create:articles | إنشاء مقالات جديدة |
| update:articles | تعديل أي مقال |
| delete:articles | حذف أي مقال |
| publish:articles | تغيير حالة النشر |
استنادًا إلى هذه الأذونات، قمنا بتعريف الأدوار التالية لنظام CMS الخاص بنا:
| الإذن/الدور | 👑 المسؤول | 📝 الناشر | ✍️ المؤلف |
|---|---|---|---|
| الوصف | يتحكم في الوصول الكامل للنظام للتحكم الشامل بالمحتوى | يمكنهم رؤية جميع المقالات والتحكم في حالة النشر | يمكنهم إنشاء مقالات جديدة في النظام |
| list:articles | ✅ | ✅ | ❌ |
| read:articles | ✅ | ✅ | ❌ |
| create:articles | ✅ | ❌ | ✅ |
| update:articles | ✅ | ❌ | ❌ |
| delete:articles | ✅ | ❌ | ❌ |
| publish:articles | ✅ | ✅ | ❌ |
ملاحظة: يحصل المؤلفون تلقائيًا على إذونات القراءة/التعديل/الحذف لمقالاتهم الخاصة، بغض النظر عن إذونات الدور.
بعد ذلك، سنقوم بتخصيص الأدوار للمستخدمين في نظامنا (باستخدام عرض CMS ك مثال):
| المستخدم | الدور |
|---|---|
| Alex | مدير نظام |
| Bob | ناشر |
| Charlie | مؤلف |
وفي Logto، كما هو مذكور في المقالة RBAC in practice أعلاه، قمنا بإعداد الأدوار لمستخدمينا.

إليك كيفية تسجيل دخول المستخدمين إلى نظام CMS الخاص بنا:
لذا، تطبيق التحكم في الوصول على API الخدمة الخاصة بك بسيط مثل إضافة وسيط للتحقق من صحة رمز الوصول والتحقق من الأذونات في الخطوة 9.
التنفيذ الأساسي كما يلي (تحقق من التنفيذ الكامل في RBAC sample - backend):
وتطبيق الوسيط على نقاط نهاية API التي تتطلب المصادقة:
لقد أضفنا الآن التحكم في الوصول إلى نظام CMS الخاص بنا وخصصنا الأدوار لمستخدمينا.
بعد تسجيل دخول المستخدمين وحصولهم على رمز الوصول لواجهة CMS API، يمكنهم استخدام هذا الرمز للوصول إلى واجهة CMS API. يحتوي رمز الوصول على معلومات إذن المستخدم. يسمح لنا هذا بالتحكم فيما يتم إرجاعه بناءً على أذونات المستخدم.
خطوتنا التالية هي تنفيذ خادم MCP لاستخدام الرموز الشخصية للوصول.
الرجوع إلى تدفق المصادقة لـ CMS أعلاه، يحصل المستخدمون على رمز وصول لـ CMS API بعد تسجيل الدخول. هذا رمز الوصول هو وثيقتهم للوصول إلى CMS API.
نحن فقط بحاجة إلى الحصول على رمز وصول مماثل للذي يحصل عليه المستخدمون بعد تسجيل الدخول. يمكننا بعد ذلك استخدامه للوصول إلى CMS API.
هنا يأتي دور الرموز الشخصية للوصول. فهي تساعدنا في الحصول على نفس نوع رمز الوصول الذي يحصل عليه المستخدمون عادة بعد تسجيل الدخول.
إليك ما يجب علينا القيام به:
في هذا المثال، نستخدم Logto للتوضيح، نظرًا لدعمه الرموز الشخصية للوصول وتبادل الرمز. إذا كنت لا تستخدم Logto، يمكنك اتباع هذا النهج لتنفيذ الدعم الخاص بك للرموز الشخصية للوصول.
في Logto Console > إدارة المستخدم، يمكنك إنشاء رمز وصول شخصي لمستخدم من صفحة تفاصيله:

عند إنشاء رمز وصول شخصي، يمكنك تحديد وقت صلاحيته حسب الحاجة.
الآن وقد حصلنا على الرمز الشخصي للمستخدم، يمكننا استخدامه في خادم MCP الخاص بنا.
أولاً، دعونا نتبع توثيق الرمز الشخصي للوصول لـ Logto، سنتحصل على رمز وصول للوصول إلى API الخاص بـ CMS من نقطة نهاية الرمز في Logto. يمكنك الاطلاع على كود المصدر الكامل هنا.
في خادم MCP، نستخدم رمز الوصول من دالة exchangeAccessToken للحصول على البيانات من CMS API.
بهذه الطريقة، لا يحتاج خادم MCP إلى بيانات اعتماد تسجيل الدخول للمستخدم للوصول إلى CMS API. بدلاً من ذلك، يستخدم الرمز الشخصي للمستخدم.
يمكنك العثور على الكود الكامل في RBAC sample - mcp-server。
لتعلم كيفية نشر هذا الخادم MCP محليًا مع Claude Desktop، اطلع على: دليل نشر خادم MCP。
يمكنك أيضًا نشر هذا الخادم على مختلف IDE لـ AI مثل Cursor، Cline، Windsurf، إلخ.
لنختبر هذا التنفيذ في Claude Desktop.
في نظام CMS الخاص بنا، أنشأ أليكس وتشارلز مقال واحد لكل منهما.
نظرًا لأن أليكس لديه دور المشرف، يمكنه رؤية جميع المقالات. أما تشارلز الذي يعتبر مؤلفًا، فلا يمكنه رؤية سوى مقالاته الخاصة.
عندما نسأل Claude عن عدد المقالات المتاحة، سيستخدم Claude أداة get-available-article-count ويطلب إذننا:

عندما نستخدم رمز الوصول الشخصي لأليكس في MCP ونسأل Claude عن عدد المقالات المتاحة، يستدعي Claude الأداة get-available-article-count ويخبرنا بوجود مقالتين.

عندما ننتقل إلى رمز الوصول الشخصي لتشارلز ونطرح نفس السؤال، يخبرنا Claude بوجود مقال واحد فقط.

رائع! لقد استخدمنا بنجاح الرموز الشخصية للوصول إلى CMS API والحصول على البيانات الصحيحة.
هذا هو بالضبط ما أردناه: نقوم بإنشاء رمز شخصي للوصول لكل مستخدم، وعندما يقوم المستخدمون بتكوين خادم MCP الخاص بهم باستخدام رمزهم، نقوم بإنشاء تجربة AI مخصصة لهم.
دعني أساعدك في كتابة قسم الملخص:
في هذا الدليل، استكشفنا كيفية ربط أدوات AI بخدماتك القائمة مع الحفاظ على التحكم المناسب في الوصول. لقد أظهرنا ذلك باستخدام نظام CMS مع تنفيذ RBAC، موضحين كيف يمكن للرموز الشخصية للوصول (PATs) حل تحديات المصادقة بأناقة.
يمكنك العثور على الكود المصدري الكامل لهذا التنفيذ في مستودع العينة RBAC، والذي يتضمن تنفيذ CMS الخلفي والأمامي وخادم MCP.
عند توزيع خادم MCP على المستخدمين، تذكر جعل الرمز الشخصي للوصول قابلاً للتكوين. هذا يسمح لكل مستخدم بـ:
يضمن هذا النهج أن يبقى تكامل AI الخاص بك آمنًا أثناء تقديم تجربة مخصصة لكل مستخدم بناءً على الأذونات الخاصة بهم ودورهم في نظامك.
أتمنى لك نجاحًا كبيرًا في عملك أثناء الشروع في رحلة تكامل AI هذه! نأمل أن تزدهر وتنمو خدماتك مع هذه الإمكانيات الجديدة للذكاء الاصطناعي! 🚀