· Part 2: the guidance part of the CASI Kit. It starts with making WCF the front end for all your data – could be datasets, Xml, custom classes, or just straight up Html. In phase 1 we take your standard WCF service and make it claims aware – that’s what allows us to take the user token from SharePoint and send it across application or data center boundaries to our custom WCF applications. In phase 2 I’ll go through the list of all the things you need to do take this typical WCF application from on premises to hosted up in Windows Azure. Once that is complete you’ll have the backend in place to support a multi-application, multi-datacenter with integrated authentication.
· Part 3: describes the custom toolkit assembly that provides the glue to connect your claims-aware WCF application in the cloud and your SharePoint farm. I’ll go through how you use the assembly, talk about the pretty easy custom control you need to create (about 5 lines of code) and how you can host it in a page in the _layouts directory as a means to retrieve and render data in web part. The full source code for the sample custom control and _layouts page will also be posted.
· Part 5: a brief walk-through of a couple of sample applications that demonstrate some other scenarios for using the custom control you build that’s described in part 3 in a couple of other common scenarios. One will be using the control to retrieve some kind of user or configuration data and storing it in the ASP.NET cache, then using it in a custom web part. The other scenario will be using the custom control to retrieve data from Azure and use it a custom task; in this case, a custom SharePoint timer job. The full source code for these sample applications will also be posted.
1. Use a custom WCF application as the front end for your data and content
2. Make it claims aware
3. Make some additional changes to be able to move it up into the Windows Azure cloud
1. Configure your WebRole project (i.e. your WCF project) to use a local virtual directory for debugging. I find this much easier to work with than the VS.NET development server for things using certificates, which you will want to do. To change this, double-click on the WebRole project properties then click on the Web tab. Select the radio button that says “Use Local IIS Web server” and then click the Create Virtual Directory button. Once the virtual directory has been created you can close the project properties.
2. Add a reference to Microsoft.Identity in your WebRole project. You MUST change the reference to Copy Local = true and Specific Version = false. That is necessary to copy the WIF assembly up into the cloud with your application package.
3. Get this WCF Hotfix: http://code.msdn.microsoft.com/KB981002/Release/ProjectReleases.aspx?ReleaseId=4009 for Win2k8 R2, http://code.msdn.microsoft.com/KB971842/Release/ProjectReleases.aspx?ReleaseId=3228 for Win2k8.
4. You MUST add this attribute to your WCF class: [ServiceBehavior(AddressFilterMode = AddressFilterMode.Any)]. So for example, the class looks like this:
5. You MUST include the following configuration data in the behavior element used by your service. It fixes issues that can occur with random port assignments in the Azure environment. To test it locally you will need to get the hotfix described in #3 above:
6. Upload the SSL certificate you are using for the WCF application to the Azure developer portal first. NOTE: The CASI Kit base class is hard-wired to use SSL so you MUST implement SSL support in your WCF Windows Azure application. Hopefully this should be an expected requirement for passing potentially sensitive data between a cloud service and SharePoint farm. Then add the certificate to the Azure role properties in Visual Studio, by double-clicking on the WebRole project name (in the Roles folder). I found that using a wildcard certificate worked fine. You need a PFX certificate though, and make sure you export all certificates in the chain when you create the PFX file. Azure will expand them all out when you upload it to the developer portal.
7. Your SSL certificate should be for someName.yourDnsName.com, even though all Azure apps are hosted at cloudapp.net. For example, my SSL certificate was a wildcard cert for *.vbtoys.com. In DNS I created a new CNAME record called azurewcf.vbtoys.com, and it referred to myAzureApp.cloudapp.net. So when I make a connection to https://azurewcf.vbtoys.com my certificate works because my request and SSL certificate is for *.vbtoys.com, but DNS redirects my request based on the CNAME record, which is myAzureApp.cloudapp.net.
8. In your Azure project double-click on the WebRole project name (in the Roles folder) and set these properties as follows:
a. Configuration tab: uncheck the Launch browser for: HTTP and HTTPS endpoint
b. Certificates tab: add the certificate you are going to use for SSL with your service. For example, in my lab I use a wildcard certificate that’s issued by my domain for all my web servers, so I added my wildcard certificate here.
c. Endpoints tab: check both the box for HTTP and HTTPS (the names should be HttpIn and HttpsIn respectively). In the HTTPS section, the SSL certificate name drop down should now contain the SSL certificate that you added in step b.
1. Use the fully-qualified name when creating the endpoint address that consumes the service, i.e. machineName.foo.com rather than just machineName. This will transition more cleanly to the final format hosted on Windows Azure and may also clear up errors that occur when your SSL certificate is designed to use a fully-qualified domain name.
2. You MAY want to add this attribute: httpsGetEnabled="true" to this element: <serviceMetadata httpGetEnabled="true" />, if you want to get your WSDL over SSL. There is currently a bug in SharePoint Designer though that prevents you from using SSL for WSDL.
3. For debugging and data connection tips see my post at http://blogs.technet.com/b/speschka/archive/2010/09/19/azure-development-tips-for-debugging-and-connection-strings.aspx.
4. In most cases you should assume your WCF service namespace is going to be http://tempuri.org. For instructions on how to change it you can read the post at http://blogs.infosupport.com/blogs/edwinw/archive/2008/07/20/WCF_3A00_-namespaces-in-WSDL.aspx.