У меня есть два ограниченные контексты:
- Приложение ASP.NET 4.0 MVC/WebForms
- OWIN Self-Hosted с ASP.NET Web API 2
Первый - это хорошо зарекомендовавший себя продукт, однако его недостаток архитектуры (SmartUI) привел к созданию сложной в обслуживании кодовой базы с учетом расширяемости и масштабируемости, теперь более заметной.
Мы итерационно решая эту проблему, введя новое бэкэнд-приложение - можно разоблачить через службы OWIN/WebAPI.
В настоящее время мы стараемся использовать аутентификацию cookie в новом приложении. Первоначально я думал, что было бы просто использовать существующий файл cookie для проверки подлинности cookie, основанный на FormsAuthenticationTicket. Очевидно, это неверно.
В нашем приложении WebForms мы используем MachineKey для обозначения нашего ключа decryptionKey и validationKey для поддержки нашей веб-фермы. В .NET4 по умолчанию алгоритм AES, если я не ошибаюсь. Я предположил, что было бы просто использовать эту информацию для создания нашего собственного TicketDataFormat, если по умолчанию этого будет недостаточно.
Изученные вещи:
- Если вы самостоятельно используете OWIN, по умолчанию TicketDataFormat использует DPAPI и не ASP.NET IIS MachineKey.
- В .NET 4.5 Microsoft сделала конвейер MachineKey MVC/WebForms более расширяемым. Вы можете заменить его своей собственной реализацией, а не просто изменять алгоритм.
В идеале мы не хотим обновлять наше основное приложение до .NET 4.5, чтобы заменить шифрование файлов cookie. Кто-нибудь знает способ интеграции OWIN CookieAuthentication с существующим FormsAuthenticationTicket?
Мы попытались создать обычай:
IDataProtector
, SecureDataFormat<AuthenticationTicket>
, IDataSerializer<AuthenticationTicket>
.
IDataSerializer будет отвечать за перевод между FormsAuthenticationTicket и AuthenticationTicket.
К сожалению, я не могу найти точную информацию о лицензировании билетов на Microsoft. Вот пример нашего примера для IDataProtector:
public byte[] Unprotect(byte[] protectedData)
{
using (var crypto = new AesCryptoServiceProvider())
{
byte[] result = null;
const Int32 blockSize = 16;
crypto.KeySize = 192;
crypto.Key = "<MachineKey>".ToBytesFromHexadecimal();
crypto.IV = protectedData.Take(blockSize).ToArray();
crypto.Padding = PaddingMode.None; // This prevents a padding exception thrown.
using (var decryptor = crypto.CreateDecryptor(crypto.Key, crypto.IV))
using (var msDecrypt = new MemoryStream(protectedData.Skip(blockSize).Take(protectedData.Length - blockSize).ToArray()))
{
using (var csDecrypt = new CryptoStream(msDecrypt, decryptor, CryptoStreamMode.Read))
{
result = new byte[protectedData.Length - blockSize];
csDecrypt.Read(result, 0, result.Length);
}
}
return result;
}
}
Это предполагает, что Microsoft добавляет IV в массив байтов. Это также предполагает, что MachineKey является используемым ключом AES. Тем не менее, я прочитал, что MS использует MachineKey для функции деривации ключей - принимая во внимание другие настройки, такие как AppIsolation, AppVirtualLocation, AppId и т.д. В принципе, это был снимок в темноте, и мне нужно немного света!
Наш текущий подход
В настоящее время мы создаем прототипы с использованием вторичного файла cookie, чтобы установить личность для нового контекста приложения вместе с существующим .ASPXAUTH. К сожалению, это означает, что сеанс скольжения синхронизируется как в AuthenticationTicket, так и в FormsAuthenticationTicket.
Связанные сообщения
Принятие файлов cookie с использованием форм ASP.NET в реализации SignalR с поддержкой OWIN?