Зависит ли роль безопасности на основе ролей в WCF от режима экземпляра?

Question

Мы используем UserNamePasswordValidator и IAuthorizationPolicy загрузить пользовательские данные роли в IPrincipal объект для аутентификации и некоторые права бизнес-уровня на нашей стороне сервера.

Таким образом, мы используем Thread.CurrentPrincipal в наших сервисных операциях для проверки прав и т. д. С риском получить больше технического, чем я должен, это static собственность на Thread класс, который означает, что у него есть глобальная область видимости экземпляра (спасибо, Тилак). Должен ли я изменить свой InstanceContextMode в будущем по причинам производительности Single эта схема обязательно сломается? Я знаю что Single требует, чтобы вы написали потокобезопасный код, так что само по себе это не просто изменение конфигурации.

Не могли бы вы также поделиться любыми ссылками на авторитетные тексты о том, какой именно тип нагрузки WCF должен уметь обрабатывать, прежде чем мне нужно будет заняться этой проблемой?

Answer 1

Вот ссылка

http://msdn.microsoft.com/en-us/magazine/cc948343.aspx

Вот мои 2 цента:

Thread.CurrentPrincipal является статическим. Это означает, что он имеет глобальную область, а не область экземпляра. Тем не менее, оно также имеет сродство к потоку... т.е. свойство помечено как [ThreadStatic] ... что означает, что оно имеет глобальную область видимости, только для текущего потока. И это отличная новость в вашем сценарии, потому что ваш код, использующий Thread.CurrentPrincipal, не должен изменяться независимо от того, работаете ли вы в одноэлементном режиме или нет.

ps Проверяйте контекст Thread, в котором работает IAuthorizationPolicy. Я отчетливо вспоминаю болевые точки при установке Thread.CurrentPrincipal в какой-то безумной внедренной политике безопасности в прошлом. Убедитесь, что ваш поток, запущенный в IAuthorizationPolicy, является тем же потоком, в котором вызываются методы Service.