личность олицетворения asp.net: откуда она взялась?

Question

Вот простой вопрос, над которым я застрял некоторое время.

Когда я установил < identity impersonate=true > в моем web.config, чтобы asp.net автоматически выдавал себя за вошедшего в систему пользователя (или за анонимную учетную записьесли не используется проверка подлинности Windows), откуда берется удостоверение, которое олицетворяет asp.net?

Этот документ: http://msdn.microsoft.com/en-us/library/ff649264.aspx показывает три места, где можно получить информацию о зарегистрированном пользователе:

Httpcontext.Current.user System.Threading.Thread.Current System.Security.Principal.WindowsIdentity.GetCurrent

Похоже, что ни одно из этих мест не соответствует идентификатору, который выдается за другогокогда я устанавливаю < identity impersonate=true > в web.config.

, я хотел бы знать, откуда исходит выдуманная личность.

В частности, , я имею в виду спросить на низком уровне, откуда именно можно получить личность во время выполнения.Я знаком с конфигурацией IIS, но я хочу знать, как идентификация извлекается во время выполнения и откуда она берется.Для обсуждения давайте предположим, что удостоверение установлено в IIS, а не в файле web.config.

Answer 1

Когда олицетворение включено, идентификация происходит из IIS.Что происходит, так это то, что ASP.NET олицетворяет токен доступа, который предоставляет IIS.

Исходный токен доступа, который использовался для запуска процесса, с которого все еще доступен.Вероятно, это является источником путаницы вокруг использования трех API, упомянутых в вопросе.

Thread.CurrentPrincipal & HttpContext.Current.User: личность пользователя на другом конце линии.

• Это информация, передаваемая в ASP.NET через токен олицетворения
• Этот токен становится идентификатором, созданным динамически на основе:
• либо: a) того, как пользователь вошел в систему (Формы или проверка подлинности Windows),
• или: b) какой параметр userName олицетворения был указан в файле web.config.

WindowsIdentity.GetCurrent: фактическая базовая учетная запись Windows, которая выполняется.

• Вот как процесс был запущен до того, как ASP.NET начал олицетворение.
• Это будет только WindowsIdentity.

Причинадублирование в HttpContext.Current.User удобно для разработчиков ASP.NET.

Редактировать:

Когда IIS настроен для работы под встроенной аутентификацией Windows, и ASP.NET имеет импеrsonation включен, следующий код позволит нам запускать код в качестве основной учетной записи.

[DllImport("advapi32.dll", CharSet = CharSet.Auto, SetLastError = true)]
public static extern bool RevertToSelf();

protected void Page_Load(object sender, EventArgs e)
{
    var me = WindowsIdentity.GetCurrent();

    // At this point:
    // me.Name = Domain\UserName
    // me.AuthenticationType = Kerberos

    if (RevertToSelf())
    {
        var underMe = WindowsIdentity.GetCurrent();
        // At this point:
        // underMe.Name = IIS APPPOOL\DefaultAppPool
        // underMe.AuthenticationType = Negotiate
    }
}

В зависимости от того, что вы пытаетесь сделать, на этой странице есть больше способов решения проблемы: http://support.microsoft.com/kb/306158

Answer 2

Вы не можете отделить часть олицетворения от части аутентификации. Я думаю, вы знаете это, так как вы пишете

... asp.net олицетворяет вошедшего в систему пользователя автоматически (или анонимную учетную запись, если не используется проверка подлинности Windows) ...

Но меня смущает предложение

Для обсуждения давайте предположим, что удостоверение установлено в IIS, а не в файле web.config.

Что именно вы подразумеваете под этим?

Но позвольте мне в любом случае дать ответ:
Предположим, вы используете IntegratedWindowsSecurity, <identity impersonate=true> и <authentication mode=Forms> в Web.config. Это будет соответствовать второй последней строке последней таблицы в Создание защищенных приложений ASP.NET: аутентификация, авторизация и безопасная связь , которые вы цитировали.

В нем говорится, что Domain\UserName будет возвращено с WindowsIdentity в этом случае. И я полагаю, вам интересно, откуда взялась эта Domain\UserName -идентификация ... Существуют некоторые ограничения на использование Kerberos, например, IE должен классифицировать URL-адрес как "Интранет" или "Локальный", но я думаю, что это здесь не важно.

Теперь важно различать установку <authentication mode=windows> в Web.config и настройку режима доступа на IntegratedWindowsSecurity (или как он там называется) в IIS. Находясь в последней таблице вышеупомянутой ссылки, мы находимся в ситуации, когда IIS установлен на IntegratedWindowsSecurity (тем не менее мы можем установить <authentication mode="windows"> в Web.config!). Поэтому IE договаривается с IIS о том, как аутентифицировать текущего пользователя, вошедшего в систему . Либо с использованием NTLM или Kerberos (в основном в зависимости от версии Windows). Вот откуда приходит Domain\UserName.

Следующая статья (о делегировании, я знаю) может пролить больше света на проблему Делегирование ASP.NET :

Встроенная проверка подлинности Windows

Когда Internet Explorer пытается получить доступ к защищенному ресурсу, отправляет IIS два заголовка WWW-Authenticate для браузер, переговоры и NTLM. Заголовок согласования отправляется только IIS работает на Windows 2000 или более поздней версии. это заголовок указывает, что IIS поддерживает Протокол согласования, который позволяет переговоры между Интернетом Explorer и IIS о том, использовать ли Kerberos или NTLM аутентификация. IIS использует Kerberos, если оба клиента (Internet Explorer 5.0 и более поздние версии) и сервер (IIS 5.0 и выше) работают Windows 2000 или более поздняя версия, и обе члены одного домена или доверенные домены. В противном случае сервер по умолчанию используется NTLM.

Поскольку NTLM аутентифицирует пользователя для IIS без предоставления пользователю учетные данные для IIS, IIS не может делегировать учетные данные этого пользователя удаленная машина.

При использовании совместно с Kerberos проверка подлинности v5, IIS может делегировать учетные данные безопасности среди компьютеров под управлением Windows 2000 или более поздней версии, которые доверенный и настроенный для делегирования.

Возможно, вы знаете эти ссылки, но я все равно их публикую:

• Олицетворение ASP.NET
• Идентификация процесса ASP.NET

EDIT:
Чтобы быть более точным, я думаю (не уверен здесь), что IIS создает WindowsIdentity из LogonToken (тот, который вы получаете, вызывая неуправляемую функцию Win32 LogonUser), используя объясненный конструктор здесь, в MSDN . Также весьма интересен пример кода в документации WindowsIdentity Class (например, IntPtrStringTypeConstructor). Тогда маркер входа должен прийти из IE.

Скотт Хансельман также писал о подобной вещи:

И я думаю, что вы сможете извлечь дополнительную информацию, если будете искать решения для «имплантации» пользовательского главного объекта в процесс аутентификации ASP.NET (обычно с использованием Application_AuthenticateRequest в Global.asax). Например, Использование пользовательского принципала с проверкой подлинности с помощью форм в ASP.NET , например.

Или можете использовать Отражатель и убедитесь сами:)

Answer 3

Если вы беспокоитесь о том, какая сущность оказывает влияние на ваше приложение, первое, что следует отметить, - это режим вашей аутентификации, такой как (Windows, Form, Passport или None)Считывание учетных данных для проверки подлинности вашего запроса зависит от режима проверки подлинности, выбранного для вашего приложения.

Answer 4

В прошлом я устанавливал идентичность для олицетворения в файле web.config.В этом случае я создал пользователя, установил пул приложений под этим пользователем и использовал это имя пользователя для олицетворения.

Answer 5

Если я не ошибаюсь, это идентификатор, установленный в IIS.Безопасность каталогов.