تمكين عملك: ربط أدوات AI بخدمتك القائمة مع التحكم في الوصول

مرحبًا بكم في الدليل حول ربط أدوات AI بخدماتك الحالية مع التحكم في الوصول!

سنستكشف كيفية تجهيز خدماتك الحالية لأدوات AI، خاصة من خلال التكامل مع LLM (باستخدام بروتوكول سياق النموذج)) ووكلاء AI مختلفين، مع معالجة تحديات التحكم في الوصول.

من خلال هذا الدليل، ستكتسب:

• تكامل AI سلس: تعرف على كيفية ربط أدوات AI بخدماتك، مما يجعل بياناتك ووظائفك متاحة في بيئات AI
• تحسين أمان API: حسّن واجهات API الخاصة بك لحماية البيانات وخصوصية المستخدم من خلال التحكم الفعال في الوصول
• تجربة AI شخصية لمستخدميك: أنشئ تجارب فريدة بمساعدة AI لكل مستخدم من خلال الرموز الشخصية للوصول

نحن نوفر موارد كاملة للتعليمات البرمجية، مشروع تجريبي مكتمل شفرات المصدر (واجهات أمامية وخلفية وخادم MCP مضمنة)، وحتى أدلة عملية لمساعدتك في بناء خدمات جاهزة لل AI من البداية.

إليك كيف يمكن لهذا الدليل تحسين عملك:

• ميزة تنافسية: عزز القدرات التقنية لخدمتك وتجربة المستخدم لتبرز في سوق تنافسي
• تعزيز قيمة المستخدم: مكن المستخدمين من اكتشاف قيمة أعمق في منتجك من خلال أدوات AI، مع زيادة معدلات الاحتفاظ ورضا العملاء
• خدمات جاهزة للمستقبل: دمج خدماتك بسلاسة مع نظام 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 لخدمتك قد لا تكون عامة. تحتاج كل نقطة نهاية إلى التحكم في الوصول، ويمكن للمستخدمين المختلفين الوصول إلى موارد وبيانات مختلفة.

لذلك، سنتحدث بعد ذلك عن كيفية إضافة التحكم في الوصول إلى خدمتك.

كيفية تنفيذ التحكم في الوصول لخادم MCP#

من المهم أن نفهم أن المستخدمين الذين يصلون إلى نظامك عبر أدوات AI هم نفس الأفراد الذين قد يستخدمون نظامك مباشرة - يعمل خادم MCP كممثل لهم عندما يتفاعلون عبر أدوات AI.

لذا عندما يصل المستخدمون إلى خدماتك من خلال أدوات AI، تنشأ تحديان عمليان للتحكم في الوصول:

• كيف يمكن لخادم MCP تسجيل الدخول إلى نظامك مثل المستخدم؟
• هل يجب أن يعيد نظامك تصميم آلية التحكم في الوصول بأكملها لمجرد استيعاب خادم MCP؟ سيكون هذا تكلفة وجهدًا كبيرين، خاصة عندما يكون لنظامك الأصلي آلية مصادقة خاصة به

المفتاح لحل هذه المشاكل هو:

كيف يمكن للمستخدمين السماح لخادم MCP بمنح الوصول من خدمتك دون استخدام بيانات اعتمادهم وتسجيل الدخول التفاعلي؟

إذا تمكنت من حل هذه المشكلة، يمكنك التفاعل مباشرة مع خدمتك عبر خادم MCP، ويمكن لخدمتك الاستمرار في استخدام آلية التحكم في الوصول المصممة مسبقًا للمستخدمين، دون الحاجة إلى إعادة تصميم نظام جديد فقط لخادم MCP!

لكن هل هذا ممكن؟

بالطبع هو كذلك! يمكننا حل هذه المشكلة بشكل مثالي باستخدام الرموز الشخصية للوصول!

توفر الرموز الشخصية للوصول (PATs) وسيلة آمنة للمستخدمين لمنح رمز وصول دون استخدام بيانات اعتمادهم وتسجيل الدخول التفاعلي. هذا مفيد لـ CI/CD، والبرامج النصية، أو التطبيقات التي تحتاج إلى الوصول إلى الموارد برمجيًا.

إليك كيف تبدو سير العمل:

لذا، طالما يدعم نظامك الرموز الشخصية للوصول (PAT)، يمكنك حل تحديات التحكم في الوصول بين أدوات AI وخدماتك الحالية دون إعادة تصميم آليات المصادقة الخاصة بك، مع ضمان أمان البيانات وحماية الخصوصية لمستخدميك.

الآن، دعونا نرى كيف نطبق ذلك عمليًا.

تنفيذ التحكم في الوصول لخادم MCP#

في هذا القسم، سنقوم بتطبيق التحكم في الوصول لخادم MCP باستخدام نظام CMS الحالي كنظامنا الأساسي.

يمكنك الاطلاع على دورة CMS كاملة التعليمات البرمجية ومصدر الشفرة في RBAC عند الممارسة: تنفيذ التفويض الآمن لتطبيقك، ولكن هذا ليس إلزاميًا، سنتناول جميع المبادئ الأساسية هنا.

نظام CMS مستند إلى Logto، منصة هوية مفتوحة المصدر شهيرة توفر حلاً شاملًا للمصادقة والتفويض، ولكن التنفيذ التقني ليس محور هذه المقالة.

تصميم الأذونات وسياسة التحكم في الوصول لخدمتك#

الخطوة الأولى في تنفيذ التحكم في الوصول هي تصميم الأذونات وسياسات التحكم في الوصول لنظامك.

في مثال CMS الخاص بنا، قمنا بتصميم نقاط نهاية API التالية استنادًا إلى RBAC (التحكم في الوصول بناءً على الأدوار) وحددنا الأذونات المطلوبة للوصول إلى كل نقطة نهاية:

تصميم الأذونات للنظام كما يلي:

استنادًا إلى هذه الأذونات، قمنا بتعريف الأدوار التالية لنظام CMS الخاص بنا:

ملاحظة: يحصل المؤلفون تلقائيًا على إذونات القراءة/التعديل/الحذف لمقالاتهم الخاصة، بغض النظر عن إذونات الدور.

بعد ذلك، سنقوم بتخصيص الأدوار للمستخدمين في نظامنا (باستخدام عرض CMS ك مثال):

وفي Logto، كما هو مذكور في المقالة RBAC in practice أعلاه، قمنا بإعداد الأدوار لمستخدمينا.

تطبيق سياسة التحكم في الوصول على API الخدمة الخاصة بك#

إليك كيفية تسجيل دخول المستخدمين إلى نظام CMS الخاص بنا:

لذا، تطبيق التحكم في الوصول على API الخدمة الخاصة بك بسيط مثل إضافة وسيط للتحقق من صحة رمز الوصول والتحقق من الأذونات في الخطوة 9.

التنفيذ الأساسي كما يلي (تحقق من التنفيذ الكامل في RBAC sample - backend):

وتطبيق الوسيط على نقاط نهاية API التي تتطلب المصادقة:

لقد أضفنا الآن التحكم في الوصول إلى نظام CMS الخاص بنا وخصصنا الأدوار لمستخدمينا.

بعد تسجيل دخول المستخدمين وحصولهم على رمز الوصول لواجهة CMS API، يمكنهم استخدام هذا الرمز للوصول إلى واجهة CMS API. يحتوي رمز الوصول على معلومات إذن المستخدم. يسمح لنا هذا بالتحكم فيما يتم إرجاعه بناءً على أذونات المستخدم.

خطوتنا التالية هي تنفيذ خادم MCP لاستخدام الرموز الشخصية للوصول.

فهم كيفية تمثيل الرمز الشخصي للوصول للمستخدمين#

الرجوع إلى تدفق المصادقة لـ CMS أعلاه، يحصل المستخدمون على رمز وصول لـ CMS API بعد تسجيل الدخول. هذا رمز الوصول هو وثيقتهم للوصول إلى CMS API.

نحن فقط بحاجة إلى الحصول على رمز وصول مماثل للذي يحصل عليه المستخدمون بعد تسجيل الدخول. يمكننا بعد ذلك استخدامه للوصول إلى CMS API.

هنا يأتي دور الرموز الشخصية للوصول. فهي تساعدنا في الحصول على نفس نوع رمز الوصول الذي يحصل عليه المستخدمون عادة بعد تسجيل الدخول.

إليك ما يجب علينا القيام به:

1. إنشاء رمز وصول شخصي للمستخدم
2. استخدام هذا الرمز الشخصي للوصول لطلب رمز تبادلي من نقطة نهاية الرمز لـ Auth Service. هذا يعطينا رمز وصول مشابه للذي يحصل عليه المستخدمون بعد تسجيل الدخول
3. استخدام رمز الوصول هذا في أداة MCP Service للوصول إلى CMS API

في هذا المثال، نستخدم Logto للتوضيح، نظرًا لدعمه الرموز الشخصية للوصول وتبادل الرمز. إذا كنت لا تستخدم Logto، يمكنك اتباع هذا النهج لتنفيذ الدعم الخاص بك للرموز الشخصية للوصول.

إنشاء رمز وصول شخصي لمستخدمك#

في Logto Console > إدارة المستخدم، يمكنك إنشاء رمز وصول شخصي لمستخدم من صفحة تفاصيله:

عند إنشاء رمز وصول شخصي، يمكنك تحديد وقت صلاحيته حسب الحاجة.

استخدام رمز الوصول الشخصي في خادم MCP#

الآن وقد حصلنا على الرمز الشخصي للمستخدم، يمكننا استخدامه في خادم 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 على المستخدمين، تذكر جعل الرمز الشخصي للوصول قابلاً للتكوين. هذا يسمح لكل مستخدم بـ:

• تكوين PAT الخاص به في خادم MCP
• الوصول إلى الموارد بناءً على الأذونات الخاصة بهم
• الحصول على تجارب AI مخصصة تعكس دورهم ومستويات الوصول الخاصة بهم

يضمن هذا النهج أن يبقى تكامل AI الخاص بك آمنًا أثناء تقديم تجربة مخصصة لكل مستخدم بناءً على الأذونات الخاصة بهم ودورهم في نظامك.

أتمنى لك نجاحًا كبيرًا في عملك أثناء الشروع في رحلة تكامل AI هذه! نأمل أن تزدهر وتنمو خدماتك مع هذه الإمكانيات الجديدة للذكاء الاصطناعي! 🚀