Федеративная аутентификация на Azure

Я использую WIF (.net 4.5) и Azure Active для аутентификации. Сайт будет находиться на Azure.

Все работает как ожидалось локально, однако, когда я помещаю его на лазурь, я получаю ошибку:

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

Я понимаю, это потому, что приложения не могут использовать DAPI, поэтому мне нужно переключиться на защиту моего приложения с помощью MAC.

Локально я добавил это в свой webconfig: -

 <securityTokenHandlers>
    <remove type="System.IdentityModel.Tokens.SessionSecurityTokenHandler, System.IdentityModel, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" />
    <add type="System.IdentityModel.Services.Tokens.MachineKeySessionSecurityTokenHandler, System.IdentityModel.Services, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" />
  </securityTokenHandlers>

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

Эта конфигурация, однако, просто дает эту ошибку:

[CryptographicException: ошибка произошла во время криптографической операции.] System.Web.Security.Cryptography.HomogenizingCryptoServiceWrapper.HomogenizeErrors(Func`2 func, Byte [] input) +115 System.Web.Security.Cryptography.HomogenizingCryptoServiceWrapper.Unprotect(Byte [] protectedData) +59 System.Web.Security.MachineKey.Unprotect(ICryptoServiceProvider cryptoServiceProvider, Byte [] protectedData, String []) +62 System.Web.Security.MachineKey.Unprotect(Byte [] protectedData, String []) +122 System.IdentityModel.Services.MachineKeyTransform.Decode(байт [] закодирован) +161 System.IdentityModel.Tokens.SessionSecurityTokenHandler.ApplyTransforms(Byte [] cookie, Boolean outbound) +123 System.IdentityModel.Tokens.SessionSecurityTokenHandler.ReadToken(XmlReader reader, SecurityTokenResolver tokenResolver) +575 System.IdentityModel.Tokens.SessionSecurityTokenHandler.ReadToken(байт [] токен, SecurityTokenResolver tokenResolver) +76 System.IdentityModel.Services.SessionAuthenticationModule.ReadSessionTokenFromCookie(Byte [] sessionCookie) +833 System.IdentityModel.Services.SessionAuthenticationModule.TryReadSessionTokenFromCookie(SessionSecurityToken & sessionToken) +186 System.IdentityModel.Services.SessionAuthenticationModule.OnAuthenticateRequest(отправитель объекта, EventArgs eventArgs) +210 System.Web.SyncEventExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute() +136 System.Web.HttpApplication.ExecuteStep(шаг IExecutionStep, Boolean & завершен синхронно) +69

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

Какой бой был WIF!

Ответ 1

Если вы не укажете machineKey в конфигурации, Azure добавит его. Но если вы создаете новую версию своего приложения и разворачиваете ее на Azure с помощью VIP-переключения, Azure генерирует новый ключ для развертывания в Staging (при условии, что ваше первое развертывание было для Production). (VIP-переключение - хороший механизм для развертывания новой версии, а затем переключения виртуальных IP-адресов между Production и Staging).

Таким образом, в основном одно решение позволяет Azure генерировать ключ, но после VIP-переключателя у вас есть проблема. Чтобы этого избежать, вы можете поймать CryptographicException в Global.asax в обработчике Application_Error, что-то вроде этого:

// Be sure to reference System.IdentityModel.Services
// and include using System.IdentityModel.Services; 
// at the start of your class
protected void Application_Error(object sender, EventArgs e)
{
    var error = Server.GetLastError();
    var cryptoEx = error as CryptographicException;
    if (cryptoEx != null)
    {
        FederatedAuthentication.WSFederationAuthenticationModule.SignOut();
        Server.ClearError();
    }
}

Метод SignOut() вызывает удаление файла cookie.

Изменить: обновленная информация о генерации machineKey, как указано @anjdreas.

Другое решение - сгенерировать machineKey, вы можете использовать IIS Manager для этого, см. Самый простой способ создания MachineKey. Если вы поместите тот же ключ во все свои веб-приложения в Azure Web Role, процесс развертывания Azure не заменит его.

Ответ 2

Ключ машины не должен быть: Windows Azure генерирует один для вас и удостоверяет, что он идентичен для каждого экземпляра вашей роли.

Об ошибке, которую вы видите: можете ли вы попробовать очистить файлы cookie?

Ответ 3

Простое очистка файлов cookie решила всю проблему для меня в этом случае.

Ответ 4

Если вы используете формы auth. вы можете выписать, когда вы поймаете исключение и разрешите своим пользователям входить в систему и создавать допустимый файл cookie

catch (CryptographicException cex)
{
    FormsAuthentication.SignOut();
}

Ответ 5

Попросить всех пользователей очистить все файлы cookie не было для меня вариантом. На этот сайт, а также в книге "Программирование Windows Identity Federation" я нашел лучшее решение (для меня, в любом случае). Если вы уже загружаете SSL-сертификат в Azure, вы можете использовать этот сертификат для шифрования вашего файла cookie во всех экземплярах Azure, и вам не нужно беспокоиться о новых машинных ключах, профилях пользователей IIS и т.д.