Странная ошибка с WIF RTM, возникает после сброса IIS - PullRequest
2 голосов
/ 22 февраля 2010

Я размещаю свое веб-приложение на Windows Server 2008 с IIS 7.5, у меня есть 2 веб-приложения: 1. Первое - это базовая служба sso (Single Sign-on) со страницей входа.2. другое веб-приложение размещено на том же веб-сервере, который использует первое приложение для sso.

Я использую WIF RTM для реализации sso,

обычно работает нормально безлюбая проблема, пользователь может войти в систему, бросить sso и перенаправить обратно на стартовую страницу.но когда я вхожу, сначала выбрасываю sso, затем перезагружаю IIS, если я возвращаюсь ко второму приложению и обновляю страницу, я получаю следующую ошибку:

Ошибка сервера в «/» приложении.Ключ недействителен для использования в указанном состоянии.Описание: во время выполнения текущего веб-запроса произошло необработанное исключение.Пожалуйста, просмотрите трассировку стека для получения дополнительной информации об ошибке и о том, где она возникла в коде.

Сведения об исключении: System.Security.Cryptography.CryptographicException: ключ недопустим для использования в указанном состоянии.

Ошибка источника: во время выполнения текущего веб-запроса было сгенерировано необработанное исключение.Информация о происхождении и местонахождении исключения может быть идентифицирована с помощью приведенной ниже трассировки стека исключений.

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

[CryptographicException: ключ недопустим для использования в указанном состоянии.]
System.Security.Cryptography.ProtectedData.Unprotect (Byte [] encryptedData, Byte [] необязательная энтропия, область DataProtectionScope) + 425
Microsoft.IdentityModel.Web.ProtectedDataCookieTransform.Decode (закодировано байт [])1018 *

[InvalidOperationException: ID1073: возникла CryptographicException при попытке расшифровать файл cookie с помощью API ProtectedData (подробности см. Во внутреннем исключении).Если вы используете IIS 7.5, это может быть связано с тем, что для параметра loadUserProfile пула приложений установлено значение false.] Microsoft.IdentityModel.Web.ProtectedDataCookieTransform.Decode (закодировано в байтах []) + 151
Microsoft.IdentityModel.Tokens.SessionSecurityTokenHandler.ApplyTransforms (cookie в байтах [], логический исходящий файл) + 109 * 1021Ml. T.SessionSecurityTokenHandler.ReadToken (средство чтения XmlReader, токен SecurityTokenResolver) + 634
Microsoft.IdentityModel.Tokens.SessionSecurityTokenHandler.ReadToken (байтовый []] sessionCookie) + 239
Microsoft.IdentityModel.Web..SyncEventExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute () +68 System.Web.HttpApplication.ExecuteStep (шаг IExecutionStep,Логическое и завершено синхронно) + 75

________________________________________ Информация о версии: Microsoft .NET Framework Версия: 2.0.50727.4927;ASP.NET версия: 2.0.50727.4927

сеанс пользователя хранится с использованием режима сеанса SQLServer, я использую для этого специальную базу данных.

Я много пробовал, и яне могу повторно решить эту проблему на моем локальном компьютере (Windows7).У кого-нибудь был подобный опыт?подскажите как решить эту проблему?

Ответы [ 3 ]

2 голосов
/ 23 февраля 2010

Я наконец решил эту проблему, изменив пользователя пула приложений на локального пользователя. проблема, вероятно, вызвана тем, что sso размещен на 64-битной ОС, эта проблема не существует, если я размещаю sso на 32-битном компьютере (даже я использую пользователя домена для пула приложений).

Теперь я использую ApplicationPoolIdentity или NetWork Service, исключение исчезло после перезапуска IIS.

Спасибо всем вам, ребята, и я так рад поделиться с вами своим решением.

1 голос
/ 23 февраля 2010

Кажется, что есть какая-то проблема безопасности, когда у вас есть несколько приложений, использующих один домен на Win Server 2008 с IIS 7.5

Если у вас есть URL http://ourdomain.com/app1 и http://ourdomain.com/app2, вы можете войти в одно приложение с помощью WIF, но при доступе к другому приложению вы получите эту ошибку. Это связано с тем, что файл cookie предназначен для домена, но если он создан app1, то app2 не сможет получить к нему доступ.

Таким образом, решение состоит в том, чтобы либо действовать как Aaron, и использовать конкретного пользователя с правами доступа, либо, как мы, делить приложения на два разных домена, то есть http://app1domain.com/ и http://app2domain.com/.

0 голосов
/ 03 сентября 2012

Это может быть потому, что у пользователя пула приложений нет постоянного профиля пользователя. Чтобы исправить это, вы можете просто запустить что-то от имени этого пользователя:

runas /user:<domain>\<user> cmd

И это создаст профиль. Впоследствии данные должны быть расшифрованы после перезапуска IIS.

...