خدمة ServiceNow تتكامل مع بوابة Bedrock AgentCore لتبادل الرموز
توفر Amazon حلاً جديداً لتسهيل تفاعل وكلاء الذكاء الاصطناعي مع أنظمة المؤسسات، مع الحفاظ على سجلات التدقيق والصلاحيات الدقيقة.

الحاجة إلى الحفاظ على هوية المستخدم
تواجه وكلاء الذكاء الاصطناعي التي تتفاعل مع واجهات برمجة التطبيقات المؤسسية تحدياً حرجاً يتمثل في الحفاظ على هوية المستخدم عبر سلسلة الطلبات. في غياب انتشار الهوية، تصل استدعاءات الواجهة إلى الخدمات الخلفية باسم التطبيق نفسه بدلاً من المستخدم الذي بدأ الإجراء. هذا الأمر يكسر سجلات التدقيق، ويتجاوز ضوابط الوصول على مستوى المستخدم، وينتهك مبدأ الامتياز الأدنى. أعلنت Amazon عن طريقة لتهيئة Amazon Bedrock AgentCore Gateway لإجراء تبادل رموز نيابة عن (OBO) مع Microsoft Entra ID، مما يتيح للوكيل استدعاء ServiceNow REST API مع الحفاظ على هوية المستخدم الداعي.

آلية عمل البوابة وتبادل الرموز
تقوم بوابة AgentCore Gateway بإجراء التبادل بشكل أصلي لكل طلب، دون الحاجة إلى دوال Lambda وسيطة أو كود مخصص. يمكن تطبيق هذا النمط على واجهات REST أخرى محمية بـ OAuth. في بيئة الإنتاج، يمكن الجمع بين انتشار الهوية و Amazon Bedrock Guardrails لتصفية المحتوى الضار والتحقق من مدخلات ومخرجات الوكيل. تتضمن البنية المعمارية ثلاثة مكونات رئيسية: تطبيق وكيل الذكاء الاصطناعي المحمي عبر تسجيل تطبيق OAuth، وخادم بروتوكول سياق النموذج (MCP) المنفذ باستخدام البوابة، وواجهة ServiceNow REST API.
تدفق طلبات OBO عبر Microsoft Entra ID
يحصل المستخدم أولاً على رمز JSON Web Token (JWT) لاستدعاء الوكيل. ثم يصادق الوكيل على البوابة برمز JWT محدد النطاق لتسجيل تطبيق الوكيل الخاص به. تقوم البوابة بعد ذلك بتبادل هذا الرمز باستخدام تدفق OBO للحصول على رمز جديد محدد النطاق لموصل واجهة ServiceNow، مع الحفاظ على هوية المستخدم الأصلية. تستقبل ServiceNow رمزاً صالحاً حيث يطابق ادعاء preferred_username مستخدماً موجوداً، وتطبق صلاحيات ذلك المستخدم على الاستدعاء. تعالج البوابة الفجوة بين معرّف عميل الوكيل ومعرّف عميل موصل ServiceNow عبر إرسال الرمز الوارد إلى نقطة نهاية رمز Entra مع بيانات اعتماد العميل والنطاق المستهدف.

متطلبات الإعداد والتسجيل
يتطلب التنفيذ حساب AWS مع وصول إلى البوابة، ومستأجر Microsoft Entra ID مع صلاحيات إنشاء تسجيلات التطبيقات. يجب أن يمتلك الحساب على الأقل دور Application Developer لتسجيل التطبيقات. كما يتطلب الأمر مثيل ServiceNow مع وصول إداري لتكوين تكاملات OAuth الواردة، ويمكن إنشاء مثيل مطور شخصي (PDI) عبر موقع المطورين. يجب إنشاء تسجيلي تطبيق في Entra: أحدهما يمثل وكيل الذكاء الاصطناعي، والآخر يمثل موصل واجهة ServiceNow.

تكوين Microsoft Entra ID
يبدأ الإعداد بإنشاء تسجيل تطبيق لموصل واجهة ServiceNow، مع ملاحظة معرّف التطبيق (العميل). يتم بعد ذلك توسيع قائمة إدارة واختيار 'Expose an API' لإضافة نطاق باسم user_impersonation باستخدام URI معرف التطبيق الافتراضي. هذا النطاق هو ما يطلبه تدفق OBO عند تبادل الرموز. ثم يتم إنشاء تسجيل تطبيق آخر للوكيل، مع ملاحظة معرّف العميل وإنشاء سر عميل (client secret) تحتاجه البوابة لإجراء التبادل. أخيراً، يتم تكوين صلاحيات API لتطبيق الوكيل لاستدعاء تطبيق موصل ServiceNow.
إعداد تكامل ServiceNow الوارد
في وحدة تحكم إدارة ServiceNow، يتم التنقل إلى System OAuth > Inbound Integrations وإنشاء تكامل وارد جديد من نوع 'Third party ID token issued by OIDC supporting identity provider'. يجب تحديد معرّف العميل من تسجيل تطبيق موصل ServiceNow في Entra. في نفس الشاشة، يتم إنشاء تكوين مزود OpenID Connect (OIDC) وإدخال عنوان URL بيانات الوصف (metadata) لمستأجر Entra. يتم ربط ادعاء المستخدم بالحقل المناسب، مثل ربط preferred_username بحقل البريد الإلكتروني في ServiceNow. إذا لم يتضمن مستأجر Entra التحقق من JTI، يجب مسح هذا الخيار، مع مراعاة ربط ادعاء uti الداخلي بادعاء jti لحماية إضافية ضد إعادة التشغيل.

تحديد نطاقات الوصول والأمان
يتم إنشاء نطاق مصادقة (auth scope) للتكامل، مثل APIConnector، مع تقييده بواجهة Table API أو أي واجهات ServiceNow أخرى يحتاجها الوكيل للوصول إليها. بعد اكتمال هذا التكوين، تقبل ServiceNow رموز الترخيص الصادرة عن البوابة. يوفر هذا الحل بنية تحتية آمنة وقابلة للتدقيق، حيث تضمن البوابة أن كل استدعاء يتم تنفيذه بصلاحيات المستخدم الفعلي وليس بصلاحيات التطبيق الوسيط، مما يعزز الامتثال الأمني في بيئات المؤسسات المعقدة.
المصادر
- AWS Machine Learning BlogServiceNow on-behalf-of token exchange with Bedrock AgentCore Gateway
تابع التسلسل الزمني





