WindowsIdentity.Impersonate в ASP.NET случайным образом «Недопустимый токен для олицетворения - его нельзя дублировать» - PullRequest
7 голосов
/ 25 января 2012

У меня есть приложение ASP.NET, которое требует, чтобы пользователи входили под своими учетными записями домена с использованием обычной аутентификации.Пользователь может сделать выбор, а затем нажать кнопку.

В какой-то момент после нажатия кнопки появляется следующий код: WindowsIdentity.Impersonate(userIdentity.Token). userIdentity имеет тип WindowsIdentity , и для него ранее было установлено значение (WindowsIdentity) User.Identity .

userIdentity хранится как переменная сеанса, и я думаю, это потому, что после нажатия кнопки страница, содержащая этот код, вызывается через AJAX.

Когда я нажимаю этот код, он работает примерно в 2/3 времени, но в 1/3 раза я получаю это исключение: Неверный токен для олицетворения - его нельзя дублировать. Я думаю, что самый большой царапина для меня - почему это работает иногда, а не в других случаях?На некоторых сессиях он работает несколько раз до сбоя.В других случаях происходит сбой.

Вот трассировка стека:

в System.Security.Principal.WindowsIdentity.CreateFromToken (IntPtr userToken)

в системе.Security.ReservationAgent.SubmitReservationRequest (Reservation Reservation, Patron patron) в C: \ dev \ RoomRes \ Resource Booker \ BLL \ ReservationAgent.cs: строка 101

в Resource_Booker.Reserve.reserve_Click (отправитель объекта, EventArgs e) в C: \ dev \ RoomRes \ Resource Booker \ Reserve.aspx.cs: строка 474

в System.EventHandler.Invoke (отправитель объекта, EventArgs e)

в System.Web.UI.WebControls.Button.RaisePostBackEvent (String eventArgument)

в System.Web.UI.Page.ProcessRequestMain (логическое значение includeStagesBeforeAsyncPoint, логическое значение includeStagesAfterAsyncPoint)

Вот смешной фактор: я не могу воспроизвести эту проблему на своей локальной рабочей станции Windows 7 x64 - хотя моя аутентификация проходит здесь неявно, так как я использую localhost - или в 32-битной среде IIS 6.0 Windows 2003.Это происходит только в довольно ванильной среде Windows 2008 R2.Все эти среды являются членами домена.

1 Ответ

10 голосов
/ 31 января 2012

По сути, то, что вы видите, не является проблемой безопасности, поскольку сеанс входа в систему кэшируется IIS в течение всего времени жизни TCP-соединения, но HTTP иногда прерывает TCP-соединение, требующее повторной аутентификации. Это будет происходить незаметно и незаметно (обрабатывается браузером), но это приведет к аннулированию токена, так как сеанс входа в систему будет разрушен после завершения TCP-соединения.

т.е. в интересах @usr он иногда работает только потому, что сеанс входа в систему такой же, так что токен такой же, поэтому токен, сохраненный в сеансе, работает, потому что это тот же фактический токен, что и User.Identity. Это не способ избежать проверки безопасности, это деталь реализации проверки безопасности.

Вы не должны хранить личность в сеансе - это не нужно, поскольку это аутентифицированное соединение.

Просто используйте (WindowsIdentity)User.Identity каждый раз, и ваша проблема исчезнет.

...