Проблема с использованием WIF с IIS6

У нас есть проблема с использованием SessionAuthenticationModule в IIS 6, при попытке доступа к приложению возникает следующее исключение:

Операция по защите данных не удалась. Это могло быть вызвано тем, что профиль пользователя не был загружен для пользовательского контекста текущего потока, что может иметь место, когда поток олицетворяет себя.

Что мне удалось выяснить, так это то, что можно включить профили в IIS 7, но наша хостинговая компания использует IIS 6. Есть идеи, что делать? Что-то попробовать или просто общие идеи?

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

[CryptographicException: The data protection operation was unsuccessful. This may have been caused by not having the user profile loaded for the current thread's user context, which may be the case when the thread is impersonating.]
    System.Security.Cryptography.ProtectedData.Protect(Byte[] userData, Byte[] optionalEntropy, DataProtectionScope scope) +456
    Microsoft.IdentityModel.Web.ProtectedDataCookieTransform.Encode(Byte[] value) +54

[InvalidOperationException: ID1074: A CryptographicException occurred when attempting to encrypt the cookie using the ProtectedData API (see inner exception for details). If you are using IIS 7.5, this could be due to the loadUserProfile setting on the Application Pool being set to false. ]
    Microsoft.IdentityModel.Web.ProtectedDataCookieTransform.Encode(Byte[] value) +146
    Microsoft.IdentityModel.Tokens.SessionSecurityTokenHandler.ApplyTransforms(Byte[] cookie, Boolean outbound) +47
    Microsoft.IdentityModel.Tokens.SessionSecurityTokenHandler.WriteToken(XmlWriter writer, SecurityToken token) +470
    Microsoft.IdentityModel.Tokens.SessionSecurityTokenHandler.WriteToken(SessionSecurityToken sessionToken) +89
    Microsoft.IdentityModel.Web.SessionAuthenticationModule.WriteSessionTokenToCookie(SessionSecurityToken sessionToken) +123

asp.net-mvc-2 iis-6 wif
person Kristoffer    schedule 27.09.2010    source источник

Ответы (4)


arrow_upward
2
arrow_downward

создайте фиктивную оконную службу и установите оконную службу в свою веб-службу и измените ее учетную запись для входа, чтобы она совпадала с учетной записью пула приложений веб-приложений. это должно работать

person david    schedule 23.03.2011

arrow_upward
1
arrow_downward

У меня была такая же проблема с локальным сервером IIS7, и я решил ее, установив для loadUserProfile значение true в пуле приложений. Я нашел следующее относительно IIS6:

В IIS6 все рабочие процессы, независимо от того, какое удостоверение процесса было настроено, использовали C:\windows\temp в качестве временного каталога. В частности, ни один из рабочих процессов не загрузил свой «пользовательский профиль» по умолчанию, в результате чего все они использовали c:\windows\temp в качестве временного каталога. Windows разрешает всем пользователям чтение/запись/создатель привилегий в этом каталоге, что позволяет «просто работать». Негативным побочным эффектом этого является то, что все пулы приложений по умолчанию фактически используют один и тот же временный каталог, что может привести к раскрытию информации между пулами приложений. В IIS7 мы выбрали более безопасный вариант по умолчанию и теперь загружаем профиль пользователя по умолчанию для всех пулов приложений.

loadUserProfile и IIS7

Таким образом, похоже, что IIS6 не должен блокировать временный каталог по умолчанию. Интересно, ваш хостер заблокировал его по тем же причинам.

person chief7    schedule 26.10.2010
comment
Спасибо, проверю, если это возможно. На самом деле мы закончили тем, что, поскольку мое приложение, размещенное у внешнего провайдера, реализовало альтернативный обработчик токенов, который использует машинный ключ (и, следовательно, не нуждается в профиле пользователя). Это не оптимальное решение, но работает как временное. - person Kristoffer; 27.10.2010

arrow_upward
0
arrow_downward

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

person Senaka Fernando    schedule 10.10.2012

arrow_upward
0
arrow_downward

Вы можете обойти необходимость в профиле пользователя, используя RSA вместо DPAPI для защиты токенов сеанса. На самом деле это лучшая практика для всех развертываний, но особенно для балансировки нагрузки (а кто не балансирует нагрузку на предприятии?)

Доминик Байер кое-что написал по этому поводу: rel="nofollow">http://leastprivacy.com/2010/02/19/wcf-wif-and-load-balancing-and-a-bit-of-azure/

person Michele Leroux Bustamante    schedule 06.08.2011