Last post Dec 16, 2013 02:52 AM by wertzui01
Dec 11, 2013 05:17 AM|wertzui01|LINK
I want to pass the authentication cookie from my ASP.Net MVC 5 (.Net 4.5.1, hosted locally on iisexpress, run from Visual Studio) to my WCF Service (.Net 4.5.1, hosted locally on WcfSvcHost, run from same Visual Studio Solution) and decrypt it there.
I have configured both to use the same machinekey (Web.config for ASP, App.config for WCF):
<machineKey validationKey="930681CA8CDC1BC09118D6B37E4A1B7712CEDBBD9FA1E35407EA1CD440C7E6F2DB9E93DADAC4098F90ACC7417DBE57C196722FC67F313A6AAE0F946E2FF731B6" decryptionKey="714C9581DA522C636B2D97D80276D5ACC02C274A11ABF117C76181B0480D4AEA" validation="SHA1" decryption="AES" />
Both reference the Same System.Web.dll:
> C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.5.1\System.Web.dll (v4.0.30319)
But when i try to pass the cookieString to my Service and call
FormsAuthenticationTicket tick = FormsAuthentication.Decrypt(cookieString);
I get the Following Error:
> Unable to validate data
I tried it the other way around (generate a fake ticket on WCF service and decrypt on ASP website), which did not work either.I can generate a ticket on the ASP website and decrypt it there just fine.I can also generate a ticket on the Service and decrypt it there without any problems.
var t1 = new FormsAuthenticationTicket("foo", false, 1337);
var cookie = FormsAuthentication.Encrypt(t1);
var t2 = FormsAuthentication.Decrypt(cookie);
I also made a small Console app, created a ticket there and decrypted it on the WCF service without any problems.
So it seems like the ASP Website does not use the specified keys to encrypt or decrypt the data.
Does anyone know what i can do to solve this problem?
Dec 11, 2013 12:16 PM|levib|LINK
In the WCF service, set <machineKey ... compatibilityMode="Framework45" />. This will cause it to use the same algorithm as ASP.NET.
Edit: If you copied + pasted your actual machine keys in the post above, remember to change them in your web application.
Dec 12, 2013 03:51 AM|wertzui01|LINK
I tried this and now i get the following Error: "Error occurred during a cryptographic operation."
bei System.Web.Security.Cryptography.HomogenizingCryptoServiceWrapper.HomogenizeErrors(Func`2 func, Byte input)
bei System.Web.Security.Cryptography.HomogenizingCryptoServiceWrapper.Unprotect(Byte protectedData)
bei System.Web.Security.FormsAuthentication.Decrypt(String encryptedTicket)
And yes, this is the key currently in use (no production environment, only development) and i know i have to change it after my question got answered :)
I just thought it might be helpfull (there could be an error related to this specific combination)
Dec 12, 2013 11:36 AM|levib|LINK
If you turn on first-chance exceptions (attach the VS debugger, then use Debug->Exceptions to break on all managed code exceptions), does the debugger give you a more detailed exception?
Dec 13, 2013 09:18 AM|wertzui01|LINK
I was running with the Debugger attached and stepped through the source, so this is the best exception, i can provide.
I now stepped through the actual Framework sourcecode and found out, that on the ASP.Net website, the following Expression is false while it is true on the WCF service:
This results in the website calling
protectedData = MachineKeySection.EncryptOrDecryptData(false, protectedData, null, 0, protectedData.Length, false, false, IVType.Random);
And the service calling the following instead:
byte buffer2 = AspNetCryptoServiceProvider.Instance.GetCryptoService(Purpose.FormsAuthentication_Ticket, CryptoServiceOptions.None).Unprotect(protectedData);
length = buffer2.Length;
protectedData = buffer2;
This happens inside the method FormsAuthentication.Decrypt
Dec 13, 2013 11:30 AM|levib|LINK
Sounds like the web site might be missing <httpRuntime targetFramework="4.5" /> in its web.config. Try adding it.
Dec 16, 2013 02:52 AM|wertzui01|LINK
Thank you, this fixed it!
I had a deeper look at what <httpRuntime targetFramework="4.5" /> does and found out, that the root cause was that the machineKey Attribute did not have compatibilityMode="Framework45" which is inferred when <httpRuntime targetFramework="4.5" /> is
added to the configuration.