|احراز هویت یکپارچه پروکسی: حساب‌های سرویس و جعل هویت
|زمینه امنیتی پشت احراز هویت یکپارچه پروکسی را بررسی کنید، هنگامی که یک برنامه به‌صورت تعاملی کار می‌کند اما به‌عنوان سرویس وب یا فرایند زمان‌بندی‌شده شکست می‌خورد.
عبارت «از اعتبارنامه‌های Windows من استفاده کن» به یک فاعل نیاز دارد. در یک برنامه دسکتاپ، فاعل می‌تواند شخصی باشد که آن را اجرا می‌کند. در یک سرویس، می‌تواند حساب سرویس باشد. در یک برنامه وب، ورود موفق یک بازدیدکننده به‌طور خودکار زمینه امنیتی درخواست خروجی را جایگزین نمی‌کند.
این توضیح می‌دهد که چرا یک مرورگر و کد سمت سرور روی یک ماشین ممکن است نتایج متفاوتی از پروکسی با احراز هویت یکپارچه بگیرند. آن‌ها ممکن است هویت‌های متفاوتی را ارائه کنند.
پیش از تغییر کد، هویت‌ها را نام ببرید
- شخصی که در مرورگر دسکتاپ وارد شده است.
- حسابی که فرایند برنامه را میزبانی می‌کند.
- هر هویت جعل‌شده‌ای که برای عملیات خروجی فعال است.
- حسابی که پروکسی واقعاً پذیرفت یا رد کرد.
در مسیرهای احراز هویت یکپارچه پشتیبانی‌شده در .NET، DefaultCredentials به زمینه امنیتی فعلی مربوط است. این یک نام مستعار جهانی برای هر کسی که صفحه‌ای را روی ماشین دیگری باز کرده نیست.
اگر محصول عمداً به‌عنوان یک کاربر عمل می‌کند، جعل هویت و هر الزام واگذاری شبکه به طراحی پشتیبانی‌شده خود نیاز دارد. روشن کردن یک کلید عمومی برای استفاده از اعتبارنامه‌های پیش‌فرض آن طراحی را ایجاد نمی‌کند. برعکس، یک کار پس‌زمینه که برای اجرا با هویت سرویس در نظر گرفته شده نباید به باز کردن مرورگر توسط کسی وابسته باشد.
راه‌اندازی تعاملی و راه‌اندازی مستقر را پس از حذف اسرار مقایسه کنید: زمینه حساب، نقطه پایانی پروکسی، روش اعلام‌شده و هویت ردشده. از کپی کردن رمز عبور دسکتاپ به برنامه فقط به این دلیل که یک درخواست یک‌باره را موفق کرد پرهیز کنید. حسابی را که برنامه باید استفاده کند پیکربندی کنید و سپس آن مالکیت را در سابقه استقرار قابل مشاهده نگه دارید.