RIA Services SP2 RTW released

We’re happy to announce the final release of WCF RIA Services V1 SP2:

In this release, we add the following new features:

  • Support for Silverlight 5 (the standalone installer linked above also supports Silverlight 4)
  • DateTimeOffset support + various bugfixes
  • Entity Framework Code-First development, using this NuGet package

Known issues include:

  • Entity Framework 4.1 is required, but version 4.2 isn’t supported yet
  • Requires Visual Studio 2010 or SP1. Visual Studio 11 isn’t supported yet
  • Work on supporting Universal Providers for improved Windows Azure deployment is ongoing
  • If you want to create a Silverlight 4 Business Application Template, first create an instance of the Silverlight 5 template, and then use the Silverlight project properties to retarget it to Silverlight 4. You might see some temporary errors (System.Windows.Markup.XamlParseException) in the designer and error window, but rebuilding will make those disappear.

“Active” Federation with Silverlight, WCF, and WIF

In this post I provided a description of the active federation authentication pattern and shared how to implement it with RIA Services. In this post I will show how to do the same but use a regular WCF service instead of a RIA Services DomainService. I am including the diagram from my last post, with some minimal modifications here.

Active federation flow with Silverlight, WCF, and WIF

I should clarify why I am putting the word active in quotation marks. The following will only make sense if you understand the difference between passive and active federation, which is outlined in the post linked above. In the passive federation case, the user never enters their credentials in the client app; they are redirected to the STS of the identity provider organization. This way the user is providing their credentials directly to the party they trust, and not to the app, which they may not trust. In the active federation case, they actually provide their credentials to the client app, and trust that the app will not be malicious, and will simply forward those credentials to the STS of the identity provider. The client app is responsible for creating a secure login UI, and also for securely transmitting the credentials to the STS. That is a lot of responsibility, and in traditional active federation scenarios, the client app uses strong encryption to guarantee the secure transfer of credentials. Still, lots of users may be reluctant to type in their credentials into a client app they don’t trust.

In this example I show how to do the active federation flow, and my client app does collect the credentials. I have hand-rolled my login UI, and cannot make any guarantees as to how secure it actually is. For the communication with the server, I simply use HTTPS, instead of more comprehensive message-level security. So my example reaps the convenience of the active flow (no need to redirect the user to a different page, login happens in-app), however may not provide the traditional security guarantees associated with it. Hence “active”. 

What I provide here may be perfectly secure for many scenarios but is up to you, the developer, to assess if this particular setup satisfies the requirements of your users and your organization. 

Now some specifics of the sample. It’s a simple app that can draw squares on the screen according to a Fibonacci tiling. There are two registered users: fabrikam\yavor and fabrikam\test and the password for both of them is 12345. Both can log into the app, however only the fabrikam\yavor user is in the role Calculators, meaning people who can carry out calculations on the service. This is enforced by the following attribute on the service’s GetSequence method.

[PrincipalPermission(SecurityAction.Demand, Authenticated = true, Role = "Calculators")]
public int[] GetSequence(int max)

The bottom line here is that even though we have a STS with external user authentication, we kept authorization local to our app (we use ASP.NET roles). That’s a choice you can make as a developer - you can also externalize the user roles (or claims) as part of the STS, or keep them local.

There are lots of extra details in the app, which you’ll see by exploring the source.

The code is available here. The solution should be fairly self-contained, so all you need to run it is Visual Studio 2010 and the Windows Identity Foundation Runtime. Here are some additional notes on the structure of the sample:

  • First, please run the included SetupCertificates.cmd script inside the Scripts folder
  • The solution will create two applications in your local IIS instance: FibonacciService and IdentityProviderAndSts. Make sure you launch Visual Studio as Administrator, so it has permission to create those. Also make sure you enable HTTPS so both of the applications in the IIS Manager

I want to credit the folks behind the Identity Developer Training Kit, from where I shamelessly stole some code.

Hosting WCF NetTcp services in Azure with a Silverlight client

UPDATE: Folks from the Windows Azure team have posted an improved solution for how to host NetTcp services in Azure by using a WebRole instead of a WorkerRole, which simplifies the setup quite a bit.

Silverlight 4 added support for WCF’s NetTcpBinding, which is a performant and scalable TCP-based binding. It is also a useful binding when used in Windows Azure because it is not affected by Azure’s random load-balancer when using multiple instances of the service and creates an effectively pinned duplex connection to the cloud. The only disadvantage of the NetTcp binding is that it Silverlight does not support TCP transport security, so all the traffic to the web service is unsecured and can be intercepted by malicious parties. That may or may not be acceptable for your application.

I put together a sample on how to host a NetTcp service in Azure and consume it using a Silverlight client. The first thing to keep in mind here, is that Silverlight has some networking restrictions for security reasons. One of this restrictions is that if you want to speak TCP to a server, the server has to expose a policy file over port 80 explicitly listing the ports that it allows TCP for. Moreover, the ports have to be in the range 4502-4530. In other words if my Silverlight app wants to talk to net.tcp://contoso.cloudapp.net:4502, then I need to expose a policy file at http://contoso.cloudapp.net:80

Another interesting concern here is that hosting WCF NetTcp services is only allowed in Azure Worker Roles. This is because the Azure Web Role (which is basically an IIS instance) does not have WCF non-HTTP activation enabled.

My sample actually shows two separate approaches on how to implement this. If you already have an external web server where you host static HTML content as well as your Silverlight XAP file, the sample shows an approach using a single Worker Role.

NetTcp service in Azure with Silverlight with single Worker Role

Now if you don’t have an existing webpage, you are probably already considering a Web Role, where you can host the static HTML files and Silverlight XAP file. In that case we can make our life easier by reusing that WebRole to host the clientaccesspolicy.xml file as well. This diagram shows that approach: Web Role + Worker Role.

NetTcp service in Azure with Silverlight with a Web Role + Worker Role

To run the sample, you need to install the following:

  • Visual Studio 2010
  • Windows Azure SDK v1.4
  • Windows Azure Tools for Microsoft Visual Studio 2010 Platform v1.4

Keep in mind that when you run the sample locally in the development fabric, it will not run correctly, because the the emulator cannot use port 80. Since the policy file has to be hosted on port 80, calls from Silverlight to the service will fail. This gets resolved when you publish the sample to the cloud.

You can get the sample code here. 

Some cool shots from the Silverlight Firestarter event.

Silverlight Firestarter demo

In my previous post I linked to the video and slides from my talk. This point contains the code sample, which is available here.

Setting up your machine

Here is what you need on the machine before you get started:

  • Windows 7
  • Visual Studio 2010
  • Silverlight 4 tools for Visual Studio 2010
  • SQL Server 2008 Express (which I’m pretty sure comes with Visual Studio 2010 by default)
  • IIS7

Before you proceed, make sure the user account under which SQL Server Express is running is NETWORK SERVICE. If you don’t remember how this was installed, open up Task Manager (make sure you select “Show processes from all users”) and look for the sqlsevr.exe process. If you find that you need to change the user, this topic on MSDN should come in handy.

The other tricky part is installing/configuring IIS. Go to the search box in the Start menu and type “Turn Windows features on or off”, then select top result. In the box shown, make sure the following are checked.

Deploying the basic app

  1. Download the zip file and unzip the content in a folder such as C:\Firestarter. It is actually very important to download this in a location other than your C:\Users\YourUser folder, due to an apparent bug with SQL Server Express.
  2. Open Visual Studio as Administrator and open the solution file. You will be prompted to create a new website in IIS, and you should agree. If this succeeds you should see the solution open with both projects loaded correctly. But we’re not quite done yet.
  3. We need to make sure the account under which IIS is running has access to SQL Express. Go into the IIS Manager (type inetmgr into the Start menu search box) and click on Application Pools. Find the ASP.NET v4.0 application pool and then select Advanced Settings on the right side. Find the Identity row and change that to NetworkService.

  4. We also need to make sure that the NETWORK SERVICE user has access to the location where we put our files. Let’s assume you used C:\Firestarter as I recommended above. Go to the the folder properties, then go to the Security tab. NETWORK SERVICE is part of the Users group on any machine, so we can just make sure that the Users group has read and write  permission. If you don’t see  the Users group go ahead and add the NETWORK SERVICE account explicitly here and give it read and write permission. Make sure the permissions are inherited all the way down, especially to the App_Data folder and the .mdf files inside that folder. You should double-check that every .mdf file allows the Users group or the NETWORK SERVICE account read and write permission. Otherwise you will get a stream of inexplicable errors as you attempt to follow the rest of this post.

You should now be able to hit F5 in Visual Studio, the application should pop up and you should be able to see the book categories and click on individual books.

At this point you can also try and use the demo to enable the debugging features I cover in the video.

Setting up Windows Authentication

Needless to say, before we can demonstrate this scenario, we need to make sure the machine we are using is joined to a domain.

We need to do the IIS configuration step that I refer to in the video, but I don’t show. We can open IIS Manager and find our web application, then double-click the Authentication icon and make sure Windows Authentication is enabled.

We can then follow the rest of the steps as shown in the video. One exception is that instead of my personal domain credential, you will need to specify your own domain credential in the BookService.svc.cs code behind file. In the download I’ve changed it to domain\user.

Setting up Forms Authentication

Before we can get this to work, we need to first configure our website for access over HTTPS. Like I mention in the video, this authentication scheme requires HTTPS.

  1. Back in IIS Manager we need to enable HTTPS on the Default Web Site bindings list. You can follow this tutorial by ScottGu.
  2. Once the HTTPS binding is created for the parent website, we need to enable the HTTPS protocol for our BookService.Web site. We can do that by going to Advanced Settings and adding https in the list of Enabled Protocols. The values are comma-separated in case you were wondering.

  3. If you end up using a self-signed certificate, realize the IE will display an error page warning you that the cert is not signed. That means that any calls that Silverlight tries to make to that page will be blocked automatically. The easiest way to fix this is to go over to Internet Options > Advanced and in the Security section deselect “Warn about certificate address mismatch”. Don’t forget to restart IE afterwards, and most importantly, don’t forget to reenable this option when you are done playing with the demo.
  4. The last thing we need to realize is that we will be accessing the SL application over HTTP, but internally it will be making calls to HTTPS services. This is cross-scheme access and is normally disabled, even for same-domain calls. To address this we need a special clientaccesspolicy.xml file, which we place at the root of our IIS install, in my case that is C:\inetpub\wwwroot. The file looks like this:
    <?xml version="1.0" encoding="utf-8"?>
    <access-policy>
       <cross-domain-access>
          <policy>
             <allow-from http-request-headers="SOAPAction">
                <domain uri="http://localhost"/>
             </allow-from>
             <grant-to>
                <resource path="/BookShelf.Web" include-subpaths="true"/>
             </grant-to>
          </policy>
       </cross-domain-access>
    </access-policy>
    

Once all of this is done, we can go ahead and follow the steps in the video. Please look carefully at both Web.config and ServiceReferences.ClientConfig to make sure you comment out all sections that refer to ASP.NET authentication.

That is it, please let me know if you hit any issues in the comments.

Cheers,
-Yavor