2012-05-28 4 views
8

Я использую WIF для аутентификации нашего нового веб-сайта, STS основана на реализации стартеров.WIF-ID1014: Подпись недействительна. Возможно, данные были изменены с помощью

Чтобы это правильно работало в среде с балансировкой нагрузки, я использовал следующее в global.asax, чтобы переопределить поведение сертификата по умолчанию.

void onServiceConfigurationCreated(object sender, ServiceConfigurationCreatedEventArgs e) 
     { 
      List<CookieTransform> sessionTransforms = new List<CookieTransform>(new CookieTransform[] 
      { 
       new DeflateCookieTransform(), 
       new RsaEncryptionCookieTransform(e.ServiceConfiguration.ServiceCertificate), 
       new RsaSignatureCookieTransform(e.ServiceConfiguration.ServiceCertificate) 
      }); 

      SessionSecurityTokenHandler sessionHandler = new SessionSecurityTokenHandler(sessionTransforms.AsReadOnly()); 
      e.ServiceConfiguration.SecurityTokenHandlers.AddOrReplace(sessionHandler); 
     } 

Это все работает просто найти, и люди успешно используют систему, однако каждый сейчас, и тогда мы получим взрыв:

ID1014: подпись не действительна. Возможно, данные были подделаны.

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

ID1074: Криптографическое исключение произошло при попытке шифрования файла cookie с использованием API защищенных данных (см. Внутреннее исключение для подробностей). Если вы используете IIS 7.5, это может быть связано с тем, что для параметра loadUserProfile в пуле приложений установлено значение false.

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

Любые идеи, которые могут мне помочь?

+0

Спасибо за ответ, в два раза проверено все, что и он отлично работает, может видеть, что точки останова находятся в ловушке, а также выводится трассировка. У меня есть FederatedAuthentication.ServiceConfigurationCreated + = onServiceConfigurationCreated; В старте приложения. – RubbleFord

ответ

2

Я изменил реализацию, чтобы исправить таймаут в методе ontokencreated. Это предотвращает переиздание.

protected override void OnSessionSecurityTokenCreated(Microsoft.IdentityModel.Web.SessionSecurityTokenCreatedEventArgs args) 
     { 
      args.SessionToken = FederatedAuthentication.SessionAuthenticationModule.CreateSessionSecurityToken(
       args.SessionToken.ClaimsPrincipal, 
       args.SessionToken.Context, 
       DateTime.UtcNow, 
       DateTime.UtcNow.AddDays(365), 
       true 
       ); 
      //base.OnSessionSecurityTokenCreated(args); 
     } 
+0

Что делает это переопределение в точности с точки зрения исключения, которое вы получали? – ABC

+0

Прошу прощения, я не помню, мне нужно взглянуть на кодовую базу. – RubbleFord

+0

Спасибо, если у вас есть шанс, не могли бы вы мне сообщить? – ABC

0

Вы пытались установить параметр loadUserProfile в значение true? Остается ли проблема?

(Выберите пул приложений в IIS, а затем нажмите «Дополнительные настройки» справа. «Загрузить профиль пользователя» находится в разделе «Модель процесса»).

+0

Мы не пробовали это, потому что мы используем RSA, а не DPAPI. – RubbleFord

3

Файлы cookie браузера зашифрованы «старым» механизмом - DPAPI. Следовательно, когда сервер пытается дешифровать файлы cookie, он терпит неудачу - ваш код использует RSA сейчас, а не DPAPI.

Как обходной путь, очистите кеш браузера, и приложение запустится как ожидалось.

+0

Мы никогда не использовали другую систему, поскольку мы находимся в сбалансированной нагрузке среде. – RubbleFord

0

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

Это может быть длинный снимок, но в вашем фрагменте кода я заметил, что ваш метод переопределения «onServiceConfigurationCreated» начинается с нижнего регистра o. Такая опечатка действительно помешает вам правильно переопределить поведение по умолчанию WIF.