![]() |
#8 |
Moderator
|
Это приводит к тому, что сервер которому разрешена эта делегация может обращаться к другим компьютерам от имени пользователя прошедшего на нем авторизацию. Классический пример из мира CRM 3.0: Система развернута на двух компьютерах 1 - CRM, 2- SQL + Reporting Services. Пользователь заходит на сайт CRM и система с радостью его авторизует. Данные из базы SQL вычитываются под служебной учетной записью, так что проблем на этом участке не возникает. Теперь пользователь решает выполнить отчет. Здесь часть логики реализует CRM сервер - параметры предварительной фильтрации и другие интерфейсные вещи, а часть сайт Reporting Services. Вот в этот момент возникает вторая авторизация: клиент не обращается к Reporting Services напрмую через браузер. За него это делает CRM система, но есть одно важное НО: в данном случае она не может работать под выделенной учетной записью которой можно все: данные в отчете должны быть персонифицированы. Иными словами, запрос к приложению Reporting Services должен быть выполнен от имени пользователя, а не CRM системы. Это и есть право на делигирование: это разрешение доверять промежуточному серверу имперсонировать пользователя: говорить "Я = Вася" не предоставляя его пароль.
Доверительные отношения между доменами при это затронуты быть не должны. Какие "ресурсы" бояться опубликовать ваши админы я вообще не понимаю!
__________________
http://fixrm.wordpress.com, снятие/наведение порчи. Быстро, дорого, гарантия. ![]() ![]() |
|
|
За это сообщение автора поблагодарили: alesander (1), fakir89 (1). |
|
|