I have two bounded contexts:
- ASP.NET 4.0 MVC/WebForms Application
- OWIN Self-Hosted w/ ASP.NET Web API 2
The former is an existing well-established product, however, its lack of architecture (SmartUI) has led to an difficult-to-maintain codebase with concerns of extensibility and scalability now more glaringly visible.
We are iteratively addressing this issue by introducing a new backend application - exposable via OWIN/WebAPI services.
Currently we're only looking to leverage cookie authentication in the new application. Originally, I thought it would be a breeze to use existing cookie auth/validation based upon FormsAuthenticationTicket. Evidently this is not true.
In our WebForms application, we make use of MachineKey to designate our decryptionKey and validationKey to support our web farm. In .NET4, the default algorithm is AES if I'm not mistaken. I assumed it would be simple to leverage this information to build our own TicketDataFormat if the default wouldn't suffice.
First things learned:
- If you self-host with OWIN, the default TicketDataFormat uses DPAPI and not ASP.NET IIS MachineKey.
- In .NET 4.5, Microsoft has made the MVC/WebForms MachineKey pipeline more extensible. You can replace it with your own implementation and not just change the algorithm.
Ideally, we're not looking to update our main application to .NET 4.5 to replace cookie encryption. Does anyone know of a way to integrate OWIN's CookieAuthentication with an existing FormsAuthenticationTicket?
We tried creating custom:
IDataProtector
, SecureDataFormat<AuthenticationTicket>
, IDataSerializer<AuthenticationTicket>
implementations.
The IDataSerializer would be responsible for translation between FormsAuthenticationTicket and AuthenticationTicket.
Unfortunately, I can't find accurate information regarding Microsoft's ticket encrpytion. Here is our example idea for 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;
}
}
This assumes Microsoft prepends the IV to the byte array. This also assumes the MachineKey is the AES key used. However, I have read that MS uses the MachineKey for a key derivation function - taking into account other settings like AppIsolation, AppVirtualLocation, AppId, etc. Basically, this was a shot in the dark and I need some light!
Our Current Approach
We're currently prototyping using a secondary cookie to establish identity for the new application context alongside the existing .ASPXAUTH. Unfortunately, this means keeping session sliding in sync in both AuthenticationTicket and FormsAuthenticationTicket.
Related Posts
Accepting ASP.NET Forms Authentication cookies in an OWIN-hosted SignalR implementation?