1: <\/span><<\/span>securityTokenHandlers<\/span>><\/span><\/pre>\n 2: <\/span> <<\/span>add<\/span> type<\/span>="System.IdentityModel.Services.Tokens.MachineKeySessionSecurityTokenHandler,
System.IdentityModel.Services, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089"<\/span> \/><\/span><\/pre>\n 3: <\/span> <<\/span>remove<\/span> type<\/span>="System.IdentityModel.Tokens.SessionSecurityTokenHandler,
System.IdentityModel, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089"<\/span> \/><\/span><\/pre>\n 4: <\/span><\/<\/span>securityTokenHandlers<\/span>><\/span><\/pre>\n<\/div>\nI know, it\u2019s clipped and wrapped badly: eventually I\u2019ll change the blog theme. For the time being, you can copy & paste to see the entire thing.<\/p>\n
Note, the above is viable only if you are targeting .NET 4.5 as it takes advantage of a new feature introduced only in the latest version. If you are on .NET 4.0 WIF 1.0 offers you the necessary extensibility points to reproduce the same capability (more details below) however there\u2019s nothing ready out of the box (you could however take a look at the code that Dominick<\/a> already nicely wrote for you here<\/a>).<\/p>\nNow that I laid down the main point, in the next section I\u2019ll shoot the emergency flare that will lead your search engine query here.<\/p>\n
Again, Adagio<\/h1>\n
Let\u2019s go through a full cycle of create a WIF app -> deploy it in Windows Azure Web Sites \u2013> watch it fail \u2013> fix it \u2013> verify that it works.<\/p>\n
Fire up VS2012, create a web project (I named mine \u201cAlphaScorpiiWebApp\u201d, let\u2019s see who gets the reference ;-)) and run the Identity and Access Tools<\/a> on it. For the purpose of the tutorial you can pick the local development STS option. Hit F5, and verify that things work as expected (== the Web app will greet you as \u2018Terry\u2019).<\/p>\nDid it work? Excellent. Let\u2019s try to publish to Windows Azure Web Site and see what happens. But before we hit Publish, we need to adjust a couple of things. Namely, we need to ensure that the application will communicate to the local development STS the address it will have in Windows Azure Web Sites, rather than the one on localhost:<port> automatically assigned (ah, please remind me to do a post about realm vs. network addresses). That\u2019s pretty easy: go back to the Identity & Access tool<\/a>, head to the Configure tab, and paste in the Realm and Audience fields the URL of your target Web Site. <\/p>\n![\"image\"](\"http:\/\/cloudidentity.com\/blog\/wp-content\/uploads\/2013\/01\/1781.image_5F00_5316A090.png\" "\\"image\\"")
<\/a> <\/p>\nGiven what we know, we better turn off the custom errors before publishing (usual <customErrors mode="Off">under system.web).<\/p>\n
Done that, go ahead and publish. My favorite route is through the Publish\u2026 entry in the Solution Explorer, I have a .PublishSettings file I import every time. Ah, don\u2019t forget to check the option \u201cRemove additional files at destination\u201d.<\/p>\n
![\"image\"](\"http:\/\/cloudidentity.com\/blog\/wp-content\/uploads\/2013\/01\/2043.image_5F00_523E3AA6.png\" "\\"image\\"")
<\/a> <\/p>\n<\/p>\nReady? Hit Publish and see what happens.<\/p>\n
\n\n\n\nServer Error in ‘\/’ Application. <\/p>\n
<\/h3>\nThe data protection operation was unsuccessful. This may have been caused by not having the user profile loaded for the current thread’s user context, which may be the case when the thread is impersonating.<\/i><\/h4>\n
Description: <\/b>An unhandled exception occurred during the execution of the current web request. Please review the stack trace for more information about the error and where it originated in the code. <\/p>\n
Exception Details: <\/b>System.Security.Cryptography.CryptographicException: The data protection operation was unsuccessful. This may have been caused by not having the user profile loaded for the current thread’s user context, which may be the case when the thread is impersonating. <\/p>\n
Source Error:<\/b> <\/p>\n
An unhandled exception was generated during the execution of the current web request. Information regarding the origin and location of the exception can be identified using the exception stack trace below.<\/code><\/p>\nStack Trace:<\/b><\/p>\n
<\/code><\/p>\n <\/p>\n[CryptographicException: The data protection operation was unsuccessful. This may have been caused by not having the user profile loaded for the current thread's user context, which may be the case when the thread is impersonating.]\n System.Security.Cryptography.ProtectedData.Protect(Byte[] userData, Byte[] optionalEntropy, DataProtectionScope scope) +379\n System.IdentityModel.ProtectedDataCookieTransform.Encode(Byte[] value) +52\n\n[InvalidOperationException: ID1074: A CryptographicException occurred when attempting to encrypt the cookie using the ProtectedData API (see inner exception for details). If you are using IIS 7.5, this could be due to the loadUserProfile setting on the Application Pool being set to false. ]\n System.IdentityModel.ProtectedDataCookieTransform.Encode(Byte[] value) +167\n System.IdentityModel.Tokens.SessionSecurityTokenHandler.ApplyTransforms(Byte[] cookie, Boolean outbound) +57\n System.IdentityModel.Tokens.SessionSecurityTokenHandler.WriteToken(XmlWriter writer, SecurityToken token) +658\n System.IdentityModel.Tokens.SessionSecurityTokenHandler.WriteToken(SessionSecurityToken sessionToken) +86\n System.IdentityModel.Services.SessionAuthenticationModule.WriteSessionTokenToCookie(SessionSecurityToken sessionToken) +148\n System.IdentityModel.Services.SessionAuthenticationModule.AuthenticateSessionSecurityToken(SessionSecurityToken sessionToken, Boolean writeCookie) +81\n System.IdentityModel.Services.WSFederationAuthenticationModule.SetPrincipalAndWriteSessionToken(SessionSecurityToken sessionToken, Boolean isSession) +217\n System.IdentityModel.Services.WSFederationAuthenticationModule.SignInWithResponseMessage(HttpRequestBase request) +830\n System.IdentityModel.Services.WSFederationAuthenticationModule.OnAuthenticateRequest(Object sender, EventArgs args) +364\n System.Web.SyncEventExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute() +136\n System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously) +69\n <\/pre>\n <\/code><\/p>\n
Version Information:<\/b> Microsoft .NET Framework Version:4.0.30319; ASP.NET Version:4.0.30319.17929 <\/td>\n<\/tr>\n<\/tbody>\n<\/table>\nWhat happened, exactly? It\u2019s a well-documented phenomenon. By default, WIF protects cookies using DPAPI and the user store. When your app is hosted in IIS, its AppPool must have a specific option enabled (\u201cLoad User Profile\u201d) in order for DPAPI to access the user store. In Windows Azure Web Sites, that option is off (with good reasons, it can exact a heavy toll on memory) and you can\u2019t turn it on. But hey, guess what: even if you could, that would be a bad idea anyway. The default cookie protection mechanism is not suitable for load balanced scenarios, given that every node in the farm will have a different key: that means that a cookie protected by one node would be unreadable from the other, breaking havoc with your Web app session.<\/p>\n
What to do? In the training kit for WIF 1.0 we provided custom code for protecting cookies using the SSL certificate of the web application (which you need to have anyway) \u2013 however that is an approach more apt to the cloud services (where you have full control of your certs) rather than WA Web Sites (where you don\u2019t). Other drawbacks included the sheer amount of custom (code required (not staggering, but non-zero either), its complexity (still crypto) and the impossibility of making it fully boilerplate (it had to refer to the coordinates of the certificate of choice).
\n
In WIF 4.5 we wanted to support this scenario out of the box, without requiring any custom code. For that reason, we introduced a cookie transform class that takes advantage of the MachineKey, and all it needs to opt in is a pure boilerplate snippet to be added in the web.config. Sometimes I am asked why we didn’t change that to be the default, to which I usually answer: I have people waiting for me at the cafeterias to yell at me for having moved classes under different namespaces (sorry, that\u2019s the very definition of \u201cmoving WIF into the framework\u201d :-)), now just imagine what would have happened if we would have changed the defaults :-D.<\/p>\n
More seriously: you already know what the fix is: it\u2019s one of the two methods described in the \u201cStraight to the Point\u201d section. Apply one of those, then re-publish. You\u2019ll be greeted by the following:<\/p>\n
![\"image\"](\"http:\/\/cloudidentity.com\/blog\/wp-content\/uploads\/2013\/01\/2867.image_5F00_78A01DF1.png\" "\\"image\\"")
<\/a> <\/p>\n<\/p>\n![\"image\"](\"http:\/\/cloudidentity.com\/blog\/wp-content\/uploads\/2013\/01\/3021.image_5F00_170A5EDB.png\" "\\"image\\"")
<\/a> <\/p>\n