|المصادقة المتكاملة عبر البروكسي: حسابات الخدمة والانتحال

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

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

سمِّ الهويات قبل تغيير الشيفرة

• الشخص المسجل الدخول في متصفح سطح المكتب.
• الحساب الذي يستضيف عملية التطبيق.
• أي هوية منتحلة نشطة للعملية الصادرة.
• الحساب الذي قبله البروكسي فعليًا أو رفضه.

على مسارات المصادقة المتكاملة المدعومة في .NET، يتعلق DefaultCredentials بسياق الأمان الحالي. وهو ليس اسمًا مستعارًا عامًا لكل من فتح صفحة على جهاز آخر.

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

قارن التشغيل التفاعلي والتشغيل المنشور بعد إزالة الأسرار: سياق الحساب، ونقطة نهاية البروكسي، والطريقة المعلنة، والهوية المرفوضة. وتجنب نسخ كلمة مرور سطح المكتب إلى التطبيق لمجرد أنها جعلت طلبًا واحدًا ينجح. اضبط الحساب الذي يُفترض أن يستخدمه التطبيق، ثم أبقِ هذه الملكية ظاهرة في سجل النشر.