This Toolkit is now deprecated and is now

superseded by Windows Azure Mobile Services

The Windows Azure Toolkit for Windows Phone provided developers with the first iteration of support for building backend services for Windows Phone apps using Windows Azure.  The main areas of feedback we received from mobile developers was that they wanted a turn-key set of services for common functionality such as notifications, auth, and data.   Windows Azure Mobile Services directly reflects this feedback by enabling developers to simply provision, configure, and consume scalable backend services. The downloads for this toolkit will be removed on the week of Feb 1st 2013 and all future improvements will be channeled into Windows Azure Mobile Services rather than this toolkit. 

To get started with Mobile Services, sign up for a Windows Azure account and receive 10 free Mobile Services.


This section provides an overview of the services and proxies included in the Windows Azure Toolkit for Windows Phone.

 

Proxies and Services for Windows Azure Storage

Every request made against the Windows Azure Storage Services must be authenticated (unless the request is for a blob or container resource that has been made available for public or signed access).

An authenticated request requires two headers: the Date or x-ms-date header and the Authorization header. The latter, contains a request signature that is generated with the key for the account that is making the request. This means that to perform operations to these services, you require to have access to the storage account secrets.

To avoid having to store your secrets (the storage account name and key) in your phone client applications, the toolkit provides a set of proxies and services that let you consume the Windows Azure Storage Services in a secure fashion. This way, the storage account information remains safe in the Web Role hosting these services:

  • The Azure Tables and Queues proxies are HTTP Handlers that forward requests to the real Windows Azure Storage Services. These proxies support different authentication mechanisms, like Membership and ACS, and allow a more granular level of authorization on top of the storage resources. If the proxy determines that the request has the correct privileges, it will sign the request, forward it to the real Windows Azure Storage Services, and then forward back the response to the client.
  • The Shared Access Signature service is a WCF REST Service that delivers Shared Access Signatures (SAS) for containers and blobs. A SAS is a set of URL query parameters that incorporates all of the information necessary to grant controlled access to a blob or container resource. The URL specifies the time interval over which the SAS is valid, the permissions that it grants, the resource that is to be made available, and the signature that the Blob service should use to authenticate the request. Once the phone client receives the SAS, it can use it to perform requests to the Blob Service REST API.

image

For more information, you can review the following articles:

 

OData Service for SQL Azure

The SQL Azure OData Service is a sample WCF Data Service built on top of a SQL Azure (or SQL Server) database using Entity Framework 4.1 Code First.

The current version of this service only supports Read operations and, in addition to exposing the SQL Azure database as an OData feed, it adds a security layer to manage authentication / authorization.

image

For more information, you can review the following articles:

 

Microsoft Push Notifications

The Microsoft Push Notification Service in Windows Phone offers third-party developers a resilient, dedicated, and persistent channel to send data to a Windows Phone application from a web service in a power-efficient way. The toolkit provides an enhanced notification service built on top of the MPN service that saves the notifications sent to the user while he is offline, and delivers them to him the next time he logs in.

The Windows Phone, the MPN service and the toolkit service collaborate in this way:

  1. The Windows Phone Application registers in the MPN service: The WP application opens a notification channel to the MPN service. The WP application indicates that it wishes to receive push notification messages. The MPN server creates a subscription endpoint associated with that particular channel, so the notifications received at that endpoint will be forwarded to that specific WP device, and that specific WP application, using the channel it’s just opened. The MPN server sends the endpoint to the WP application, so the WP application can send the endpoint to the service it wants to receive notifications from.
  2. The Windows Phone Client registers in the Toolkit Web Role: The WP application invokes the SamplePushNotificationService in the Web Role to register itself with the subscription endpoint received from the MPN service. This endpoint is the URI to which the cloud application will perform the HTTP POSTs to send PN messages to the device.
  3. The Toolkit Cloud Service sends a notification request to the MPN Service: The cloud services sends a notification request by doing a HTTP POST in a specific XML format defined by the MPN protocol to the subscription endpoint associated with the device it wants to notify.
  4. The MPN service sends the notification to the WP device: The MPN transforms the notification request it received to a proper Push Notification to send to the WP device associated with the endpoint where it received the notification request. The notification request can ask for a toast, a tile, or a raw notification. Once the WP device receives the PN via the Push Client it will route the notification to the Shell, which will take an action according to the status of the application. If the application is not running, the shell will either update the application tile, or show a toast. If the application is running, it will send the notification to the already running application.

When sending Tile or Toast notifications from the Administration Portal, the full text of the notification is stored either in an Azure Queue (if available) or in a SQL Azure database table (if this is the only storage medium available). When the phone application is launched, and the Notifications pivot item selected, this queue or database table is polled and all the messages for that user are extracted and shown to the user.

image

For more information, you can review the following articles:

 

ACS Authentication

 

The Windows Azure Access Control Service (ACS) allows your application to outsource authentication, enabling users to register and log in from the Windows Phone client by reusing their existing accounts from identity providers such as Windows Live ID, Google, Yahoo and possibly from an Active Directory or Facebook.

The phone application pulls a list of the available Authentication Providers from the configured ACS namespace, and the users authenticate themselves with one of those providers. After that, the Simple Web token provided by ACS is stored in the device and it is used to sign every HTTP request made to the services. All services check the validity of this token before authorizing a request to pass through to Windows Azure Storage or SQL Azure.

After authenticating against an Authentication Provider the phone application checks against the Web Role if the user is already registered. If he is registered, he is redirected to the registration page, where he is asked for a name and an email address.

The username is used by the administration to grant or revoke granular permissions for each of the Services and Proxies in the Web Role.

 

image

 

Membership Authentication

ASP.NET membership enables developers to validate and manage user information for your Web application. It provides functionality for validating user credentials, creating and modifying membership users, and managing user settings such as passwords and e-mail addresses. ASP.NET membership is primarily intended for use with ASP.NET forms authentication, but can be used anywhere within an ASP.NET application.

When the Windows Phone Application is configured using Membership as authentication service, users must create a user in the Web Role, using the Phone Application. Once a user is created, they can access all services deployed in the Web role for which the administrator grants permission to. The Phone Application uses the Authentication ticket provided by ASP.NET membership to sign every request made to the Web Role. All services check the validity of this ticket before authorizing request to pass through to Windows Azure Storage or SQL Azure.

The username is used by the administration to grant or revoke granular permissions for each of the Services and Proxies in the Web Role.

If the Web Role was deployed with the Windows Azure Storage services and proxies, the Windows Azure ASP.NET Membership Providers are used to store the Authorization information in your Windows Azure Storage account, otherwise, the ASP.NET Universal Membership Providers are used to store this information in a SQL Azure database.

 

image

For more information, you can review the following articles:

 

 

Administration Portal

All Windows Phone Cloud Applications come bundled with an Administration Portal that allow administrators to:

  • Grant / Revoke permissions for users on:
    • Blob Containers
      • Individually for each container
      • For all containers
    • Windows Azure Queues
      • Individually for each queue
      • For all queues
    • Windows Azure Tables
      • Individually for each table
      • For all tables
    • SQL Azure
      • Read access to the OData service.
  • Send Microsoft Push Notifications
  • Send Apple Push Notifications

The administrator users are authenticated using ASP.NET Membership. If the Web Role was deployed with the Windows Azure Storage services and proxies, the Windows Azure ASP.NET Membership Providers are used to store the Authorization information in your Windows Azure Storage account, otherwise, the ASP.NET Universal Membership Providers are used to store this information in a SQL Azure database.

image

For more information, you can review the following articles:

 

Next step: FAQs

Last edited Jan 21, 2013 at 8:24 PM by nharris, version 24

Comments

payini Feb 18, 2012 at 4:23 AM 
This is great content. Very useful. Thanks.