Exercise 1: Authenticating Users via ACS and invoking via OAuth2 an OData Service in a Windows Phone 7 app
Let’s say that you developed a Windows Phone 7 application, composed by one Silverlight client and one OData service, which allows the creation and editing of to-do lists.
The to-do lists are saved in the cloud, in Window Azure’s storage, via the OData service (hosted in Windows Azure as well). The application has no concept of individual users, hence all the lists are accessible by anyone who runs the client. Wouldn’t it be nice to enable each user to define his own private lists?
In order to add the private lists feature, the application needs to gain the two new capabilities below:
Adding authentication capabilities to your WP7 application can be very complicated if you have to handle everything from scratch: luckily, you don’t have to. The Windows Azure AppFabric Access Control Service (ACS) can take care of brokering authentication for you, enabling the user to authenticate with well-known providers. If you want to know more about ACS, you can take a look at the dedicated hands-on labs in the training kit. For the purpose of this lab, the main way in which you will interact with ACS is via a Silverlight control, which you can include in your WP7 application and that will take care of all runtime interactions with the service. All that is left to do for you is to configure the service, via its handy management portal, and specify your preferences such as which identity providers you want to enable and similar.
Adding authentication and authorization capabilities to the OData service, again, could be a lot of work if approached from the wrong angle. The current way of securing REST services is via the OAuth 2 protocol. The protocol per se is pretty simple and handling it directly would be feasible, however as you have learned going through this training kit taking a dependency on the specific details of the protocol leads to high-maintenance code. Once again, luckily you don’t have to. Windows Identity Foundation (WIF) does not support OAuth 2 out of the box, however its extensibility model can be leveraged to add new protocols. In this hands-on lab you will use some WIF extensions which enable you to secure WCF REST services via OAuth 2. This will allow you to keep your service code completely free from authentication- and authorization-specific code; it will also allow you to leverage the rich WIF programming model for handling claims-based authorization just like you would when using the out-of-the-box protocols.
This first exercise will be all about adding those two capabilities to the described application. More in detail, you will follow the sequence below:
Task 1 – Exploring the Initial Solution
In this task, you will explore the initial solution to familiarize with its structure.
Feel free to explore the code if you want to: we kept the solution as simple as possible in order to make it easier to add the extra functionalities in the following tasks.
Task 2 – Configuring AppFabric Access Control Service with multiple identity providers
In this task, you will configure your own Access Control Service namespace to use multiple identity providers and recognize the MyTodo OData service as a registered application. You will do everything in this task through the Windows Azure AppFabric management portal.
Note. ACS makes use of claims-based identity. In claims-based identity the successful outcome of one authentication operation is expressed by issuing a security token. A security token contains a list of attributes (called claims) which describe the authenticated user. In a nutshell, ACS operates by brokering token requests to multiple identity providers (IPs); once ACS receives a token from one IP, it applies some processing logic to it and issues a transformed token to the application it protects. The advantage for the application is that it is now decoupled from the details of how every IP operates, and just needs to deal with one single broker. Everything is based on open standards, hence there is no lock-in; the moment in which the application developer wants to use a different service, switching is a simple config line away.Giving a concise yet exhaustive description of ACS and claims-based identity is difficult, but operating the service is actually very simple. The indications in this task are mainly aimed at helping you to move along through the hands-on lab scenario. If you want to gain a deeper understanding of how ACS works, please refer to the other ACS hands-on labs in the training kit.
You are done with configuring ACS. Now it’s time to start modifying the projects.
Task 3 – Securing an OData Service with OAuth2 and Windows Identity Foundation
In this task, you will add an OData Service that will provide authentication to the solution. To do that, you will include an OData authentication project, provided by this Hands-On-Lab and then you will update the configuration .
For simplicity, the MyTodo solution provided in this lab does not use HTTPS. In a real world scenario, it is highly recommended to use HTTPS for the communication with the secure service.
Task 4 – Adding Authorization for Private Lists
At this point, the MyTodo OData service has been secured: any existing clients invoking the service without adding authentication information will not gain access. However, we still don’t have implemented the private list feature: right now you need to be authenticated in order to call the service, but once you do it, there is no restriction to which lists you can see. In this task, you will add authorization logic that will properly restrict access in order to implement the private lists feature.
Task 5 – Adding Authentication to a WP7 Application
In this task, you will finally add authentication to the WP7 application. In order to do that you will include a project containing a control which wraps much of the communication with ACS and session management, then you will write the necessary code to integrate the control in your app and configure it to use your ACS namespace
Exercise 1: Verification
It is time to give your newly secured Windows Phone 7 application a spin.
In order to verify that you have correctly performed all steps in exercise one, you will first create a private list and one task. Then, you will log in with a different user to verify that the created list is not visible.
To perform this verification you need to have at least two accounts in either Windows Live ID, Google, Yahoo! or Facebook.