MachineKey Azure SDK 1.5 / 1.6

Question

Я использую собственную реализацию Api Token с использованием WCF Web API в Azure.Это использует FormsAuthentication.Decrypt для получения FormsAuthenticationTicket.Чтобы убедиться, что процесс decrpyt работает в нескольких экземплярах, я указал MachineKey в своем файле web.config.Однако я заметил, что MachineKey, похоже, не работает в Azure, потому что похоже, что Azure использует случайный машинный ключ и перезаписывает тот, который я указал в web.config. Я использую последний Azure SDK 1.5 (или1.6?)

Мне хорошо известна эта проблема с Azure SDK 1.3, и я считаю, что она была исправлена ​​в 1.4.Есть ли вероятность того, что эта проблема вновь появилась в Azure SDK1.5 / 1.6?

Answer 1

У меня возникла та же проблема, когда мои билеты FormsAuthentication не проверялись в поддоменах после недавнего обновления Microsoft .Net 4.0 Security KB2656351.

Мои билеты FormsAuth генерируются с моих выделенных серверов и читаются в поддоменах в Windows Azure.

Чтобы все домены могли расшифровывать билеты, я удостоверился, что все мои выделенные серверы были исправлены последними обновлениями .Net через Центр обновления Windows. Затем я обновил свой проект Azure до версии 1.6 и выбрал последнюю версию ОС Azure после развертывания. Казалось, это сработало.

Вот несколько статей о проблеме:

http://weblogs.asp.net/scottgu/archive/2011/12/28/asp-net-security-update-shipping-thursday-dec-29th.aspx

http://technet.microsoft.com/en-us/security/bulletin/ms11-100.mspx

ура

Francesco

Answer 2

ОК, поэтому у меня возникла проблема, как описано выше в группе NLB с 3 серверами.

Похоже, что автоматические обновления Windows установили KB2656352, KB2656358 и KB2657424 на двух из трех серверов.

Я бы положил деньги на тот факт, что некоторые серверы работают с патчем, а некоторые нет. Я думаю, что машины, которые были исправлены, не любят декодировать вещи, закодированные непатчированной машиной (и / или наоборот).

В любом случае, я установил все три исправления на оставшуюся машину и вернул их в группу NLB. Вроде все работает нормально.

Answer 3

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

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

В любом случае, я прошу прощения за причиненные неудобства.

Answer 4

Кажется, у нас та же проблема.Мы устанавливаем машинный ключ в файле web.config.Все было хорошо до тех пор, пока пару дней назад Decrypt не начал возвращать ноль.Ключ дешифрования и ключ проверки идентичны на всех машинах.Не уверен, в чем проблема.

РЕДАКТИРОВАТЬ - Azure v1.6, похоже, соответствует машинному ключу, который мы установили в файле конфигурации.Мы выяснили, как решить нашу проблему - возможно, это поможет вам - мы увидели, что расшифровка cookie не работает на наших машинах с 64-разрядной версией Windows 7.Затем мы проверили ожидающие обновления, и было несколько обновлений .NET, связанных с безопасностью.Мы запустили обновления и вуаля все снова заработало.

Answer 5

Windows Azure уже синхронизирует машинные ключи для одной и той же роли в развертывании.Таким образом, у вас должно получиться полностью игнорировать параметр MachineKey в web.config и просто позволить Windows Azure обработать его для вас (сценарий веб-фермы хорошо поддерживается).Ваш сценарий поддерживается в Windows Azure без каких-либо изменений (просто вызовите Decrypt).

Проблема, о которой вы могли говорить, была проблема 1.3, когда файлы web.config были изменены непосредственно для синхронизациимашинные ключи.Это не удалось, когда файл был доступен только для чтения (т. Е. Управление исходным кодом TFS) и вызвало сбои развертывания.Это было исправлено некоторое время назад.