Я все еще немного запутался с терминологией здесь. Но я думаю, что вы в беде:)
По моему мнению / пониманию, следующие два утверждения уже говорят вам, что то, что вы хотите, невозможно:
Мне сказали, что для каждой страницы
подключается к нашему серверу SQL, мне нужно
сделать так, чтобы пользователь подключался
используя учетную запись Active Directory.
против
Однако силы, которые здесь находятся, не
как олицетворение;
Я бы сказал, что первое утверждение подразумевает подражание . Кстати, я считаю, что это очень распространенное требование. Главным образом по той причине, которую вы указали: она позволяет вам видеть, кто что делает в вашей базе данных. Это может даже быть (или стать) требованием закона ... Обычно вам не нужно давать разрешения отдельным лицам, хотя я склонен использовать группы / роли.
Теперь в своем комментарии к @Mauro вы пишете
У меня есть cookie, который содержит объявление
аккаунт я хочу выполнить SQL
запрос как. Мой единственный вопрос, как сделать
Я заставляю процесс asp.net запускать SQL
запрос как личность, указанная
печенье?
Что вы подразумеваете под "содержит учетную запись AD"? Просто имя пользователя или имя пользователя и пароль ? Если у вас есть оба, вы можете (должны?) Следовать статье MSDN ( WindowsImpersonationContext ), упомянутой @Jeff Siver (или это то, что вы и ваше руководство называете «загромождением кода»?).
Если у вас нет пароля, вам не повезло. Как бы вы могли запустить что-то с привилегиями определенного пользователя, не предоставляя системе никакой подсказки (кроме имени пользователя), что вам разрешено это делать? Сейчас я не вижу, как здесь может помочь печенье. Если - хм - может быть, вы могли бы свернуть своего собственного руководителя безопасности ? Это выше меня, хотя.
В случае, если у нас (пока) нет одинакового понимания некоторых терминов: это будет (или, скорее, мой) список «обычных подозреваемых», способных привести к недоразумениям.
- Аутентификация Windows: опция в IIS вместо встроенной аутентификации Windows в SQL Server
- Олицетворение: Параметр ASP.NET (как указано @JustLoren) против имитации в коде ("загроможденный код"?)
- Делегирование: передача учетных данных из IIS в SQL Server (например) против тройного перехода (передача учетных данных из IE (или браузера) в IIS в SQL Server; также является своего рода делегирование)
UPDATE
WIF, кажется, приносит определенную сложность, см. Рисунок 7 и Рисунок 8 в Обзор архитектуры на основе утверждений , которую можно найти в Windows Identity Foundation Упрощает доступ пользователей для разработчиков . И я должен признать, что я не знаю WIF. Из того, что я вижу, это может действительно помочь вам; или это может просто "переложить проблему" ...
НО от вашего комментария
У меня есть участник безопасности с учетной записью AD пользователя
Я думаю, что вы могли бы изменить личность пользователя, «запускающего веб-приложение» (то есть совершающего вызовы в базу данных), используя механизм, который также можно использовать для развертывания вашего собственного «решения принципала безопасности».
Я не уверен, что вам все еще нужен impersonate в Web.config, как предложено @JustLoren. Но это вполне может быть.
Вы бы начали с замены текущего участника безопасности на «свой» (тот, который вы получаете через C2WTS) в Global.asax s Application_AuthenticateRequest -методе (надеюсь, он все равно будет вызываться, если вы разрешите анонимный доступ? !?). Но будьте осторожны Я бы сказал, это отнюдь не тривиально.
Вы можете найти больше информации (и предупреждений) здесь:
ОБНОВЛЕНИЕ2
Итак .... Вы говорите, что ответ
на мой вопрос может быть как-то
заменить текущий участник безопасности
в этом методе?
Это то, что я имел в виду, да. Вот пример кода (отрывки чего-то без WIF, который я знаю, чтобы работать).
Класс пользовательских принципов (который вам не нужен):
using System;
using System.Collections.Generic;
using System.Web;
using System.Security.Principal;
namespace PrincipalTest
{
[Serializable]
public class MyPrincipal : WindowsPrincipal
{
public MyPrincipal(WindowsIdentity ntIdentity) : base(ntIdentity)
{
}
public bool IsAdmin
{
get
{
bool isAdmin = (string.Compare(this.Identity.Name,
@"<domain>\<user>", StringComparison.OrdinalIgnoreCase)
== 0);
return isAdmin;
}
}
}
}
В Global.asax (здесь вы бы использовали магию WIF):
protected void Application_AuthenticateRequest(object sender, EventArgs e)
{
DotnetReportingPrincipal principal =
new MyPrincipal(HttpContext.Current.User.Identity
as WindowsIdentity);
// Attach the new principal object to the current HttpContext object
HttpContext.Current.User = principal;
System.Threading.Thread.CurrentPrincipal
= System.Web.HttpContext.Current.User;
}
Затем вы можете делать такие вещи (опять же, в вашем случае это не требуется):
protected void Page_Load(object sender, EventArgs e)
{
IPrincipal current = HttpContext.Current.User;
if (current is MyPrincipal)
{
if (current as DotnetReportingPrincipal).IsAdmin)
{
...
}
}
}
В вашей ситуации я бы попробовал (надеюсь :)), что вы можете просто настроить ASP.NET на использование олицетворения (опять же, как предложено @JustLoren). Надеемся, что IIS передаст «нового» пользователя SQL Server для запросов.
Если это не так, убедитесь, что ваша конфигурация допускает делегирование. Вот несколько подсказок:
Пожалуйста, помните, что я здесь на очень тонком льду. Но - кто знает ...
Возможно, вам удастся добиться чего-то, что было продемонстрировано в демонстрационной версии Microsoft, совсем неплохо:)
Удачи!
Anotherupdate
Хм - я не уверен, что мне нравится, как здесь идут дела;) Я искренне надеюсь, что не указал вам неправильное направление ...
Как вы сказали, есть класс WindowsClaimsIdentity:
есть класс в WIF, что я не
знакомы с Android
WindowsClaimsIdentity, который кажется
Быть гибридом Windows / Претензий.
Я пытаюсь найти, как настроить мой
олицетворение с использованием этого класса.
Но там написано:
Если клиент использует Windows
аутентификация , создайте
WindowsClaimsPrincipal. Этот принципал
позволяет скачивать WindowsPrincipal
и WindowsIdentity (для доступа к вещам
как олицетворение и другие окна
особенности безопасности).
И ваш клиент не использует проверку подлинности Windows, я полагаю. Так что не будет WindowsPrincipal; что является плохой новостью.
Чтобы ваш сценарий сработал, вам, в конце концов, нужен WindowsPrincipal, я вполне убежден. Это потому, что я считаю, что это единственное, что вы можете передать SQL Server. Итак, вопрос: как вы получаете WindowsPrincipal из "вашего печенья"?
То, как вы сейчас делаете что-то, вы, кстати, уже можете получить WindowsPrincpal; но не тот, боюсь. Зачем? Потому что у вас нет <authentication mode="Windows" /> в вашем Web.config. Или, если он у вас есть и вы разрешаете анонимный доступ (что вы и делаете), вы в конечном итоге получите учетную запись Windows Principal NETWORK SERVICE или компьютера (вы можете легко проверить это и сказать, если я ошибаюсь).
Кстати: у вас есть любой <authentication mode="..."> в Web.config? Я так не думаю!?!
Итак, еще раз: как вы можете получить WindowsPrincipal для текущего пользователя из имеющейся у вас информации cookie?
Вот мои мысли (я должен признать, что они оставляют во рту немного дурного запаха; это похоже на переизобретение колеса (SSO) ...).
- Настройте ваше приложение, чтобы разрешить анонимный доступ в IIS (как я понимаю, это требование).
- Настройте приложение на использование олицетворения (см.
Web.config, см. Ответ @ JustLoren)
- Используйте код в разделе «Получение токена Windows для исходного абонента» в Как: использовать переход по протоколу и ограниченное делегирование в ASP.NET 2.0 , чтобы получить
WindowsIdentity в Global.asax s Application_AuthenticateRequest -метод (используя информацию об имени пользователя и пароле, которую можно надеяться получить из «системы cookie»). - Создайте
WindowsPrincipal из этого WindowsIdentity, как описано в разделе «Чтобы создать объект WindowsPrincipal для отдельной проверки», шаг 2 в Как: создать объект WindowsPrincipal ;по сути, делая WindowsPrincipal MyPrincipal = new WindowsPrincipal(MyIdentity);. - Прикрепите созданный вами
WindowsPrincipal к текущему HttpContext и потоку (как предложено в "Update2"). - Скрестите пальцы :) Но я уверенуверенность в этом.Шаткая часть, кажется, получить правильный
WindowsIdentity ...
Yetanontherupdate
В разделе «Выдавать себя за конкретного пользователя в коде» статьи Как реализовать олицетворение в приложении ASP.NET используется еще один способ получения WindowsIdentity из имени пользователя / пароля: LogonUserA импортировано из advapi32.dll.
Maybefinalupdate
После вашего последнего обновления я вижу яснее.Вы абсолютно правы с вашим вопросом.Насколько я знаю, изменение (или влияние на) того, что возвращает WindowsPrincipal.GetCurrent, возможно только путем активации проверки подлинности Windows и отключения анонимного доступа в IIS.Что вы не можете сделать.
Но подождите!
Ого, это становится грязным.Но когда я увидел тэг "kludge" в вашем вопросе, я осмелюсь написать следующее ... Но будьте осторожны: я почти уверен, что это , а не , что Microsoft показала в этой демонстрации, которую вы упомянули :) Ни то, ни другоелюбые нежелательные побочные эффекты!
То, что вы должны быть в состоянии сделать (мой быстрый и грязный тест показал, что оно работает), это
- Добавить поле
System.Security.Principal.WindowsImpersonationContext в Global.asax - В
Global.asax с Application_AuthenticateRequest получите WindowsIdentity для пользователя, которого вы хотите выдать себя за другого (вы, кажется, можете сделать это, поскольку вы можете выдать себя за пользователя в коде) - Все еще в
Global.asax s Application_AuthenticateRequest выдавать себя за пользователя (в коде, как вы делали ранее или как описано в статье (статьях), приведенной выше; например, здесь ), не вызовimpersonationContext.Undo() ... - В
Global.asax с Application_EndRequest вызов impersonationContext.Undo() на поле, которое вы создали за два шага до - Сохранить
<identity impersonate="true" /> в Web.config - Крест все пальцы рук и ног:)
Правда, вы бы тогда все равно выдавали себя за пользователя в коде (т. Е. "Загромождали свой код имперсами").onation "), но только слегка :) Имеется в виду только в одном месте (Global.asax).
Что вы считаете?
@ Rising Star: кстати: в вашем комментарии от 2010-05-31 14:03:31Z вы пишете «Он говорит, что вы можете снять флажок , а затем ...».Это намеренно или вы хотели написать «чек»?Потому что, если вы снимите флажок в этом поле, вы должны проверить что-то еще, чтобы разрешить доступ кому-либо еще.Что бы вы (или он) проверили вместо этого?Аутентификация по формам (поскольку здесь нет «аутентификации по волшебной флейте», как вы правильно отметили здесь :))?Извините, я (автоматически) до сих пор неверно истолковываю его как "чек" ...
Обновление (от Rising Star) Я вижу, вы преобразовали эту ветку в вики сообщества, поэтому я больше неприходится вручную обновлять вопрос.Это будет беспорядок, но как только проблема будет решена, мы можем немного ее исправить.
scherand спросил, как мне прикрепить Windows Identity к cookie.Это делается с использованием инфраструктуры WIF;в частности, я делаю это, возвращая WindowsClaimsPrincipal из ClaimsAuthenticationManager, как описано в предоставленной мною ссылке "наименьшие привилегии".Кроме того, да, босс сказал снять флажок поле «анонимный доступ» в настройках IIS;кажется, это все ломает.
Я думаю, вы можете быть на правильном пути со своим ответом.Я просто пытался сделать свой собственный код в global.asax сам.