In my last post I described all steps that were needed to get a WP7 app connecting to a WCF Service using SSL and a self-signed certificate. What needs to be added to this solution is username/password authentication.

It turns out that this is pretty easy, after reading the post ‘Windows Phone 7 Data Access Strategies: Security’ by Andrea Boschin.

Replace the custom binding of the service for a basic http binding:

             1: <binding name="customBinding">

             2:  <security mode="TransportWithMessageCredential" >

             3:  <message clientCredentialType="UserName" />

             4:  </security>

             5: </binding>

Add a custom username/password validator to the service:

             1: 
            public
            class MyPasswordValidator

             2:  : UserNamePasswordValidator

             3: {

             4: 
            public
            override
            void Validate(string userName, string password)

             5:  {

             6: 
            if (!AuthenticateUser(userName,
password))

             7: 
            throw
            new SecurityTokenValidationException("...");

             8:  }

             9:  

             10: 
            private
            bool AuthenticateUser(string userName, string password)

             11:  {

             12: 
            return userName == "foo"

             13:  && password == "bar";

             14:  }

             15: }

And add it to the service behaviors:

             1: <serviceCredentials>

             2:  <userNameAuthentication 

             3:  customUserNamePasswordValidatorType="WP7toWCFtestService.MyPasswordValidator,
WP7toWCFtestService"

             4:  userNamePasswordValidationMode="Custom" />

             5: </serviceCredentials>

Refresh the service reference in the WP7 app and change the code to access the service:

             1: var ws = new Service1Client();

             2: ws.ClientCredentials.UserName.UserName = "foo";

             3: ws.ClientCredentials.UserName.Password = "bar";

             4:  

             5: ws.GetDataCompleted += ...

And voila, it is working!

Of course this is only a starting point, password should not be hard coded and you probably want to support multiple accounts. In the near future I will at least remove the username/password from the WP7 app. The user will have to supply them and they will be stored with encryption on the phone.

For my current app this single user solution is enough. When you want to support multiple users the ASP.NET Membership Framework (described in this post by Jon Simpson) can be a good option.

With the infrastructure secured it is finally time to write the actual app...

Download example

Last few evenings I’ve been working on a WP7 app that I want to connect to a new WCF service using SSL. Since it is only in a dev environment I want to use a self-signed certificate instead of an official one. Doesn’t sound too hard, does it? It took some time before it finally worked...

Dev environment
Laptop with Windows 7, IIS 7, VS2010 + Windows Phone SDK 7.1 and a Samsung Omnia 7 device (Mango).

Project

• Windows Phone app (the one in the download is very simple and only shows access to the WCF service);
• WCF Service Application; I used the default Service1 that VS2010 generates.

Step 1
First step is to get the app running, connecting with the service that runs in IIS.

• Configure the service to use IIS (hit the ‘Create Virtual Directory’ button);
• Build the service and it should be accessible from a browser, in my case http://localhost/WP7toWCFtestService/Service1.svc
• From the WP7 app add a ‘Service Reference’ to the WCF Service;

The following code connects to the service from the WP7 app:

             1: var ws = new Service1Client();

             2: ws.GetDataCompleted += 

             3:  (s, e) => UpdateStatus("Result:
" + e.Result);

             4: ws.GetDataAsync(42);

At this point the app should work and data is retrieved from the service.

Note: This is where it suddenly stopped working. After a few successful updates of the service reference Visual Studio stopped generating code in the Reference.cs. Various blogs and forums state ‘fuzzy’ solutions like restarting VS, making changes in settings, etc., but none of them worked. The only thing that did work was starting all over again with a new solution.

Create a Self-Signed Certificate in IIS, see How to Set Up SSL on IIS 7. Note that you have to use a certificate name that is equal to your web server name.

Configure the app and service to use SSL

• Add a custom binding to web.config defining httpsTransport, see web.config in the download;
• Change configuration of the Service Reference to point to the https URL and update the reference.

In case you have a real certificate everything should work now using https. However, in case of self-signed you will get the following exception:

There was no endpoint listening at https://servername/WP7toWCFtestService/Service1.svc that could accept the message. This is often caused by an incorrect address or SOAP action. See InnerException, if present, for more details.

The problem lies in the root-certificates that are accepted by Windows Phone. The exact details about the problem and how to fix this is described in several great blog posts by David Hardin: WP7 and Self-Signed SSL Certificates.

Based on his guidelines prerequisites and explained I followed these steps:

• Download the WP7CertInstaller: http://wp7certinstaller.codeplex.com;
• Removed Azure Tools reference;
• Installed the provided web site in IIS;
• Changed the URL in MainPage.xaml.cs from localhost to my server name;
• Executed the provided WP7 app to download and install the certificate.

And it works! My app now successfully connects to my service using SSL!

Next is adding credentials and removing SOAP…

Download example

In addition to my previous post Windows Azure Table Storage in the development environment I’ve created a demo application in which responsibilities are distributed over classes in a way that hides the implementation details of Azure’s table storage.

The application is pretty simple, a one page ASP.NET app in which you can add/edit movies. The movies are displayed on the same page in a GridView.

Movie model
The model has changed a bit. The RowKey is now filled with a GUID (instead of the title) to uniquely identify a movie in the table. The title now has a dedicated property. The PartitionKey remains the movie category as this helps Azure to partition the data over multiple servers if the load gets too heavy.

StorageContext

The StorageContext is the actual entry point to the data. It inherits from TableServiceContext and provides a property Movies that returns an IQueryable of type Movie, which can be used to query the data from storage. It also provides an AddMovie method to avoid exposure of the table name that is required for using TableServiceContext.AddObject.

To create a new StorageContext the StorageContextFactory can be used, which hides the creation/initialization of the StorageContext.

MovieRepository
The repository is used to access the data from the application. Creation of a MovieRepository requires a context that implements IStorageContext (e.g. StorageContext), which can be obtained by the StorageContextFactory. The reason for using an interface to the context is to be able to replace the context by some other implementation, for example in case of a non-Azure application or in case of unit-testing.

Example

             1: MovieRepository repository
= 

             2: 
            new MovieRepository(StorageContextFactory.GetContext());

             3:  

             4: 
            // Get all movies
          

             5: IEnumerable<Movie> allMovies = repository.GetAll();

             6:  

             7: 
            // Get a single movie
          

             8: Movie movie = repository.GetById(key);

             9:  

             10: 
            // Add a new movie
          

             11: Movie newMovie = MovieFactory.Create();

             12: newMovie.PartitionKey = "Action";

             13: newMovie.Title = "An action
movie!";

             14: repository.Add(newMovie);

• A MovieFactory is used to create a new Movie. In this factory an instance of a Movie is created and the RowKey property is populated with a new GUID. There are several alternatives but in this way you avoid unnecessary creation of GUIDs when objects are created by the context (in case you initialize in the Movie’s constructor), and you avoid the need for an initialization method that can potentially be forgotten to invoke.
• The Add and Update methods on repository directly save to the storage. This might not be what you want in other apps, but for this example (with only one update in each postback) it is good enough.

The source of the example can be downloaded here.

LINQ uses a Deferred Execution model which means that nothing really happens until the results of the query are accessed, e.g. in a for(each)-loop. One of the advantages of this model is that you can compose complex queries in multiple steps to make them more readable. So from a execution point of view I expected that it should not matter whether you create the query in one complex statement, or in multiple smaller statements. But unfortunately that's not always the case...

To see the difference I've created an XML document and two simple queries that create Album objects when the where-clause matches.

The 'complex' query:

             1: var query1 = from a in albums.Descendants("Album")

             2: 
            where a.Element("Artist").Value
== "Radiohead"

             3: 
            select
            new Album

             4:  {

             5:  Artist = a.Element("Artist").Value,

             6:  Title = a.Element("Title").Value

             7:  };

The decomposed, more readable query:

             1: var query2 = from a in albums.Descendants("Album")

             2: 
            select
            new Album

             3:  {

             4:  Artist = a.Element("Artist").Value,

             5:  Title = a.Element("Title").Value

             6:  };

             7:  

             8: query2 = from a in query2

             9: 
            where a.Artist == "Radiohead"

             10: 
            select a;

The result from both queries is exactly the same, but they execute differently. What happens in Query2 is that first a list of all Album objects is created and then the ‘where’ part is evaluated over each object. This is different compared to Query1 in which an Album object is only created when it matches the ‘where’ part. So in this example Query1 is more efficient.

Is this what we should expect of deferred execution with LINQ? Yes, at least on implementations based on IEnumerable<T>. What basically happens is that a chain of methods is created and executed in the same order as added to the query. This makes Query1: albums.Where(...).Select(...) and Query2: albums.Select(...).Where(...).

With implementations based on IQueryable<T>, like LINQ To SQL, this is different in a way that it uses an Expression Tree to analyze/optimize the query. Using the same two queries with LINQ To SQL both queries execute exactly the same! Only one SQL statement is send to database and they both include the where-clause, which make them equally efficient.

In this example it isn't that much a problem but when more data is involved this is definitely something to be aware of when composing LINQ queries.