{"id":3008,"date":"2014-09-15T00:59:27","date_gmt":"2014-09-15T07:59:27","guid":{"rendered":"http:\/\/www.cloudidentity.com\/blog\/?p=3008"},"modified":"2014-09-15T01:02:19","modified_gmt":"2014-09-15T08:02:19","slug":"migrate-a-vs2013-web-project-from-wif-to-katana","status":"publish","type":"post","link":"https:\/\/www.cloudidentity.com\/blog\/2014\/09\/15\/migrate-a-vs2013-web-project-from-wif-to-katana\/","title":{"rendered":"Migrate a VS2013 Web Project From WIF to Katana"},"content":{"rendered":"

As you already know, VS2013 introduced a new ASP.NET project creation experience that closely integrates with Azure AD<\/a> \u2013 allowing you to provision an entry for your application right at project creation time, without the need to visit the portal.<\/p>\n

Projects created through that experience implement their identity functionality with Windows Identity Foundation. WIF is great- it is the technology that brought claims-based identity from its obscure origin to the preferred way of securing access to cloud and in general remote resources –\u00a0 it is fully supported and it will remain supported in lockstep with the .NET Framework in which it lives. Now that we introduced a simpler claims identity programming model in Katana<\/a>, however, it does feel a bit dated!
\nThe VS tools did not really have any alternative to WIF – when the new ASP.NET project creation experience originally shipped, our support for WS-Federation and OpenId Connect in form of OWIN middleware wasn\u2019t around yet. In fact, it reached GA less than one month ago<\/a>!<\/p>\n

As we move forward, you can expect the simpler model<\/a> to replace the WIF codebase in the templates as well; but in the meanwhile, I know that a lot of you would like to make the jump already today and convert projects created and provisioned with VS2013 from WIF to OWIN. The good news is that as long as you are willing to do some light handiwork, it is quite easy to do.<\/p>\n

In this post I\u2019ll tell you about one quick & dirty way of doing that, meant to be used right after you created the project. If you developed the project further, this trick won\u2019t help you: the migration is still possible, but it would require more work to identify and eliminate the moving parts needed by WIF but no longer required by the new OWIN middleware. Let me know in the comments if many of you are in that situation, and I\u2019ll write a new post with all the details.<\/p>\n

Step 1 \u2013 Create a Web App with VS2013<\/h2>\n

You have seen this tons of times already, but I\u2019ll add the sequence again just in case.<\/p>\n

Create a new ASP.NET project.<\/p>\n

\"image\"<\/a><\/p>\n

You\u2019ll get the usual One ASP.NET dialog.<\/p>\n

\"image\"<\/a><\/p>\n

Choose MVC and click Change Authentication.<\/p>\n

\"image\"<\/a><\/p>\n

Choose Organizational Account, enter the domain of your Azure AD tenant you want to provision the app to, and click OK.<\/p>\n

\"image\"<\/a><\/p>\n

You\u2019ll get the classic ADAL dialog that prompts you for your Azure AD credentials, so that VS can reach out to your directory and create the app entry on your behalf. Note: the dialog is so long because I have an awesomely big monitor \"Smile\"<\/p>\n

Click OK again. VS will generate your project and will create an entry for it in your Azure AD tenant.<\/p>\n

The Application\u2019s Coordinates<\/h3>\n

The project creation logic generates a lot of moving parts that contribute to the identity functionality. We are going to ignore most of those, given that the OWIN middleware does not need them, and stay laser focused on the few info we do need.<\/p>\n

We need to find the coordinates that were used to create the application\u2019s entry in Azure AD, given that those values will be what we need to use when creating protocols request at authentication time \u2013 no matter which development stack we use.<\/p>\n

We\u2019ll find most of what we need in the web.config file. Open it, then find the appSettings element.<\/p>\n

  <<\/span>appSettings<\/span>><\/span>\r\n    <<\/span>add<\/span> key<\/span>=\"webpages:Version\"<\/span> value<\/span>=\"3.0.0.0\"<\/span> \/><\/span>\r\n    <<\/span>add<\/span> key<\/span>=\"webpages:Enabled\"<\/span> value<\/span>=\"false\"<\/span> \/><\/span>\r\n    <<\/span>add<\/span> key<\/span>=\"ClientValidationEnabled\"<\/span> value<\/span>=\"true\"<\/span> \/><\/span>\r\n    <<\/span>add<\/span> key<\/span>=\"UnobtrusiveJavaScriptEnabled\"<\/span> value<\/span>=\"true\"<\/span> \/><\/span>\r\n    <<\/span>add<\/span> key<\/span>=\"ida:FederationMetadataLocation\"<\/span> <\/span><\/pre>\n
      value<\/span>=\"https:\/\/login.windows.net\/developertenant.onmicrosoft.com\/FederationMetadata\/2007-06\/FederationMetadata.xml\"<\/span> \/><\/span>\r\n    <<\/span>add<\/span> key<\/span>=\"ida:Realm\"<\/span> value<\/span>=\"https:\/\/developertenant.onmicrosoft.com\/WIF2OWINWebApp\"<\/span> \/><\/span><\/span>\r\n    <<\/span>add<\/span> key<\/span>=\"ida:AudienceUri\"<\/span> value<\/span>=\"https:\/\/developertenant.onmicrosoft.com\/WIF2OWINWebApp\"<\/span> \/><\/span>\r\n  <\/<\/span>appSettings<\/span>><\/span><\/pre>\n
The highlighted part is what we need.
\nRealm<\/strong> indicates the identifies assigned to the app for WS-Federation flows.
\nFederationMetadataLocation<\/strong> is the endpoint from which Azure AD publishes the tenant\u2019s issuer coordinates. Technically, for this tutorial all you need is the tenant portion (in this case developertenant.onmicrosoft.com<\/strong>) but in the general case (e.g. any WS-Federation provider, as opposed to just Azure AD) you would need the entire metadata address.<\/p>\n
Save those values somewhere, I usally just whip them in a notepad window.<\/p>\n
Note<\/strong>: Those handy appSettings values are inserted by the ASP.NET project configurator logic; however, here there\u2019s a trick that will work with ANY web app using WIF regardless of how it was configured. If you scroll a bit further, you\u2019ll find the <wsFederation> element.<\/p>\n
 <<\/span>wsFederation<\/span> passiveRedirectEnabled<\/span>=\"true\"<\/span><\/pre>\n
   issuer<\/span>=\"https:\/\/login.windows.net\/developertenant.onmicrosoft.com\/wsfed\"<\/span><\/pre>\n
   realm<\/span>=\"https:\/\/developertenant.onmicrosoft.com\/WIF2OWINWebApp\"<\/span><\/pre>\n
   requireHttps<\/span>=\"true\"<\/span> \/><\/span><\/pre>\n
This is the element that is actually picked up by WIF at authentication time. The realm value is the same as the above. The issuer value indicates the endpoint of the STS you want to connect with; this is not as good as having the address of the metadata, but provides a great starting point given that you can usually get to it by goofing around with the base URL of the STS endpoint and append \u201cFederationMetadata\/2007-06\/FederationMetadata.xml\u201d to it to find the true metadata location.<\/p><\/blockquote>\n
The only other piece of info we need is the port number that IIS express assigned to our app for the SSL binding \u2013 that value has been used to provision the return URI in the Azure AD application entry, and unless we want to go to the portal and modify it manually we have to ensure we\u2019ll use the same value. You can find it in the project properties, in the SSL URL field.<\/p>\n
\"image\"<\/a><\/p>\n
Paste that in the same notepad window, and close VS.<\/p>\n
Step 2 \u2013 Get the Katana WS-Federation Sample and Configure it With Your App Coordinates<\/h2>\n
As I anticipated earlier, this is a quick and dirty trick. Instead of modifying the project created with the template, I will simply abandon it \u2013 and reuse its coordinates in a new project configured to use OWIN. This will take advantage of the application entry that was created for it in the Azure AD tenant.<\/p>\n
We already have a project ready for you \u2013 it\u2019s the WS-Federation sample we released with Katana. You can find it here<\/a>.<\/p>\n
From the GitHub page Choose Clone in desktop or download ZIP, whatever works best for you. Once you have the project locally, open it.<\/p>\n
Head to the web.config file. You\u2019ll find the appSettings right on top. Replace the value of ida:Wtrealm <\/strong>with the realm value you saved from the first app. Do the same with ida:Tenant and the tenant value you used in the original project.<\/p>\n
<<\/span>appSettings<\/span>><\/span>\r\n  <<\/span>add<\/span> key<\/span>=\"webpages:Version\"<\/span> value<\/span>=\"3.0.0.0\"<\/span> \/><\/span>\r\n  <<\/span>add<\/span> key<\/span>=\"webpages:Enabled\"<\/span> value<\/span>=\"false\"<\/span> \/><\/span>\r\n  <<\/span>add<\/span> key<\/span>=\"ClientValidationEnabled\"<\/span> value<\/span>=\"true\"<\/span> \/><\/span>\r\n  <<\/span>add<\/span> key<\/span>=\"UnobtrusiveJavaScriptEnabled\"<\/span> value<\/span>=\"true\"<\/span> \/><\/span>\r\n  <<\/span>add<\/span> key<\/span>=\"ida:Wtrealm\"<\/span> value<\/span>=\"https:\/\/developertenant.onmicrosoft.com\/WIF2OWINWebApp\"<\/span> \/><\/span><\/span>\r\n  <<\/span>add<\/span> key<\/span>=\"ida:AADInstance\"<\/span> value<\/span>=\"https:\/\/login.windows.net\"<\/span> \/><\/span>\r\n  <<\/span>add<\/span> key<\/span>=\"ida:Tenant\"<\/span> value<\/span>=\"developertenant.onmicrosoft.com\"<\/span> \/><\/span><\/span>\r\n<\/<\/span>appSettings<\/span>><\/span>\r\n<\/pre>\n
Note: If you would be working with a provider other than Azure AD, you\u2019d: a) skip the tenant part in the config b) go directly to App_Start\/Startup.Auth.cs, scroll to the code that initializes the WsFederationAuthenticationOptions<\/strong>, and assign to the MetadataAddress <\/strong>property the full address of the metadata document you obtained earlier.<\/p><\/blockquote>\n
Done? Very good!<\/p>\n
Now, the most delicate part. We need to tell VS that we want our project to start on the port that was assigned to the OTHER project (in this case https:\/\/localhost:44300<\/span><\/strong>\/), instead of the one port the sample was configured to run on (https:\/\/localhost:4432<\/em>0<\/span><\/strong>\/).<\/p>\n
Right-click on the project in the solution explorer and choose properties. Click on the web tab on the left.<\/p>\n
Find the Project URL field. Change the port shown there to match the one of the original project. Click Create Virtual Directory. You\u2019ll get the following warning:<\/p>\n
\"image\"<\/a><\/p>\n
VS knows that there\u2019s already a project mapped to that port, the original one, and just wants to make sure you\u2019re OK to remap that port to the current project. That\u2019s exactly what we want. Click OK. If everything goes well, you\u2019ll get a confirmation.<\/p>\n
That\u2019s it! Shift+CTRL+S for saving everything, Shift+CTRL+B for building the project. Yes, I am a big fan of shortcuts.<\/p>\n
It will take some time, given that on the very 1st build it needs to restore all NuGet packages, but it should be ready pretty soon.<\/p>\n
Once it\u2019s done, press F5.<\/p>\n
\"image\"<\/a><\/p>\n
One small difference from the original template is that this project is designed to offer an unauthenticated landing rather than imposing authentication for every resource. You can easily change this by moving the [Authorize] attribute around.<\/p>\n
Hit Sign In.<\/p>\n
\"image\"<\/a><\/p>\n
So far so good\u2026 enter the creds of any user in the target Azure AD tenant.<\/p>\n
\"image\"<\/a><\/p>\n
Aaaaaand it\u2019s done. Our OWIN-secured project successfully re-used the coordinates that the ASP.NET project creating experience originally provisioned in Azure AD.<\/p>\n
Summary<\/h2>\n
When I bought my Surface Pro 2 I was super enthusiastic. Awesome screen, great stylus responsiveness. I loved it.
\nA couple of months ago the i7 version of the Surface Pro 3 came out, and I promptly grabbed one. The screen is absolutely incredible, it is feather light, super-fast\u2026 I use it all the time, including for writing this post.
\nAnd the Surface Pro 2? It\u2019s no less great than when I got it, but I like the Pro 3 better\u2026 hence the Pro 2 is hitting eBay.<\/p>\n
You know where I am going with this. WIF is still a great technology, super flexible, 100% supported\u2026 but now that Katana is out, I\u2019d use it all the time if I could. I know this is the same for many of you, which is why I wrote this post. The support for the new model in the rest of our dev stack will come: in the meanwhile, if you have specific WIF->OWIN migration scenarios you\u2019d like to get guidance for, feel free to drop me a line<\/a> or hit me on twitter<\/a> –\u00a0 I\u2019ll do my best to help \"Smile\"<\/p>\n","protected":false},"excerpt":{"rendered":"
As you already know, VS2013 introduced a new ASP.NET project creation experience that closely integrates with Azure AD \u2013 allowing you to provision an entry for your application right at project creation time, without the need to visit the portal. Projects created through that experience implement their identity functionality with Windows Identity Foundation….<\/p>\n","protected":false},"author":1,"featured_media":3001,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_kad_post_transparent":"","_kad_post_title":"","_kad_post_layout":"","_kad_post_sidebar_id":"","_kad_post_content_style":"","_kad_post_vertical_padding":"","_kad_post_feature":"","_kad_post_feature_position":"","_kad_post_header":false,"_kad_post_footer":false,"footnotes":""},"categories":[1],"tags":[],"class_list":["post-3008","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-uncategorized"],"_links":{"self":[{"href":"https:\/\/www.cloudidentity.com\/blog\/wp-json\/wp\/v2\/posts\/3008","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.cloudidentity.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.cloudidentity.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.cloudidentity.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.cloudidentity.com\/blog\/wp-json\/wp\/v2\/comments?post=3008"}],"version-history":[{"count":2,"href":"https:\/\/www.cloudidentity.com\/blog\/wp-json\/wp\/v2\/posts\/3008\/revisions"}],"predecessor-version":[{"id":3010,"href":"https:\/\/www.cloudidentity.com\/blog\/wp-json\/wp\/v2\/posts\/3008\/revisions\/3010"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.cloudidentity.com\/blog\/wp-json\/wp\/v2\/media\/3001"}],"wp:attachment":[{"href":"https:\/\/www.cloudidentity.com\/blog\/wp-json\/wp\/v2\/media?parent=3008"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.cloudidentity.com\/blog\/wp-json\/wp\/v2\/categories?post=3008"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.cloudidentity.com\/blog\/wp-json\/wp\/v2\/tags?post=3008"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}