|ინტეგრირებული პროქსი აუთენტიფიკაცია: სერვისის ანგარიშები და იმპერსონაცია
|შეისწავლეთ ინტეგრირებული პროქსი აუთენტიფიკაციის უკან არსებული უსაფრთხოების კონტექსტი, როცა ერთი და იგივე აპლიკაცია ინტერაქტიულად მუშაობს, მაგრამ ვებ სერვისის ან დაგეგმილი პროცესის სახით იშლება.
„ჩემი Windows-ის სერტიფიკატების გამოყენებას“ სუბიექტი სჭირდება. დესკტოპ პროგრამაში ეს შეიძლება იყოს ადამიანი, რომელიც მას უშვებს. სერვისში ეს შეიძლება იყოს სერვისის ანგარიში. ვებ აპლიკაციაში ვიზიტორის წარმატებული შესვლა ავტომატურად არ ცვლის გამავალი მოთხოვნის უსაფრთხოების კონტექსტს.
ეს ხსნის, თუ რატომ შეიძლება ერთსა და იმავე მანქანაზე ბრაუზერმა და სერვერის მხარის კოდმა სხვადასხვა შედეგი მიიღონ ინტეგრირებული აუთენტიფიკაციის მქონე პროქსისაგან. შესაძლოა ისინი სხვადასხვა იდენტობას წარადგენენ.
დაასახელეთ იდენტობები კოდის შეცვლამდე
- ადამიანი, რომელიც დესკტოპ ბრაუზერში შესულია.
- ანგარიში, რომელიც აპლიკაციის პროცესს მასპინძლობს.
- ნებისმიერი იმპერსონირებული იდენტობა, რომელიც გამავალი ოპერაციისთვის აქტიურია.
- ანგარიში, რომელიც პროქსიმ რეალურად მიიღო ან უარყო.
.NET-ის მხარდაჭერილ ინტეგრირებული აუთენტიფიკაციის გზებზე DefaultCredentials მიმდინარე უსაფრთხოების კონტექსტს ეხება. ეს არ არის გლობალური ფსევდონიმი ყველასთვის, ვინც სხვა მანქანაზე გვერდი გახსნა.
თუ პროდუქტი განზრახ მოქმედებს როგორც მომხმარებელი, იმპერსონაციას და ქსელური დელეგირების ნებისმიერ მოთხოვნას საკუთარი მხარდაჭერილი დიზაინი სჭირდება. ნაგულისხმევი სერტიფიკატების გამოყენების ზოგადი გადამრთველის ჩართვა ამ დიზაინს არ ამკვიდრებს. პირიქით, ფონური დავალება, რომელიც სერვისის იდენტობად უნდა მუშაობდეს, არ უნდა იყოს დამოკიდებული იმაზე, რომ ვინმემ ჯერ ბრაუზერი გახსნას.
შეადარეთ ინტერაქტიული და განლაგებული გაშვება საიდუმლოებების მოცილების შემდეგ: ანგარიშის კონტექსტი, პროქსის საბოლოო წერტილი, გამოცხადებული მეთოდი და უარყოფილი იდენტობა. მოერიდეთ დესკტოპ პაროლის აპლიკაციაში კოპირებას მხოლოდ იმიტომ, რომ ამან ერთჯერადი მოთხოვნა წარმატებული გახადა. დააკონფიგურირეთ ანგარიში, რომელიც აპლიკაციამ უნდა გამოიყენოს, შემდეგ კი ეს საკუთრება განლაგების ჩანაწერში თვალსაჩინოდ შეინარჩუნეთ.