AZR324 – Mobile + Cloud: Mobile Apps with Windows Azure

So, you’re building apps that span multiple devices and you’re curious about what the cloud can offer. Is it possible to deploy scalable web apps and services on Windows Azure? How about storing data in the cloud? Is it possible to use the cloud for push notifications to the device? In this session, learn how to build Windows Phone, Android and even iOS apps that are backed by scalable cloud services with the Windows Azure platform.

Presented by Wade Wegner

Disclaimer: These are conference session notes I compiled during various sessions at Microsoft Tech Ed 2012, September 11-14, 2012.  The majority of the content comprises notes taken from the presentation slides accompanied, occasionally, by my own narration.  Some of the content may be free hand style.  Enjoy… Rob

Follow me on Twitter @ausrob

Entered late to the session…A session on building mobile applications for Windows Azure.

Storage Options

Storage Secrets – Authentication

Azure – storage name & key
SQL Azure – username & password (note: now named: Windows Azure SQL Database)

How to avoid storing storage credentials in a client app?

  1. Proxy the requests (via a WCF service, for example)
  2. Shared access signature (generates a sort of one time password)
    1. Device addresses storage directly

[Demo]  Using Shared Access Signature

  • Using NuGet Azure Storage package
  • Can query with REST based request
  • Can return XML or JSON
  • Returns shared access signature, client then directly requests data from Azure

Switched to Windows Phone 7 application (client).

  • Using NuGet Phone.Storage package
  • Target .Net 4.0 today unless you ship the 4.5 Framework
  • Windows Azure Storage Proxy (Cloud Services) NuGet Package
  • Storage Initializer is included.  Use it to change how storage is resolved (local or Azure)
  • Storage Service can be configured to point to the Azure Storage (using standard connection configuration)

Identity Provider Options

  • Create your own (e.g. ASP.net membership)
    • Additional scope/effort/testing
  • Use existing identity system (Facebook, LiveID etc)
    • APIs change, needs to be managed
  • Outsource identity management (Access Control Service)
    • Extra cost?
    • Allows larger base of federated identity providers
    • Claims!

Many factors to consider – management, attack vector, etc

  • Windows Identity Foundation provides claims aware capability.

[Demo] Using Access Control Service  (ACS) from Windows Phone using NuGet.

  • Demo will show how to pass an oAuth token to an Azure Service
  • Get access to the Access Control Service via the Azure Portal (Preview)
  • Create a service namespace
  • Set Identity Providers (i.e. federated identity providers, e.g. Google, Yahoo etc)
  • Add relay/realm details (sets routes, tokens supported), signing token
  • Add rules (map claims from provider to claims in an application)
    • Can be done by hand, or generated as default rules (e.g. email address –> email address)
  • Done.. consume away!

Service side – using a Delegating Handler (System.Net.Http) to validate the token before further requests are made.  Looks at request header coming in, validate token and verify against the ACS. 

Library: “Simple Web Token” (Open Source – NuGet package?) can be used to validate oAuth (simple web tokens) against the ACS.  Need to use the signing key to verify oAuth tokens against the ACS (using the previously mentioned library).

Signing key is embedded as a hash in the incoming oAuth token, FTW!  Incoming messages now are checked the header for the oAuth.  Client application now needs to pass along the token provided by the access control service.

Using ‘ACS Control for Windows Phone (NuGet).  Get the token from Application.Current.Resources.
Add to the header request.  Simple!

Communications

  • Device-initiated (pull)
  • Cloud-initiated (push)

Device:  Wire format choices (SOAP, JSON, POX)
Cloud: Notification (Toast/Title, Tile) and Raw – note: no guarantee of delivery

Subscribing to Push

  1. Device requests a channel
  2. NS returns channel (register device)
  3. Channel URI is stored in cloud
  4. Use channel URI to push message to device (via notification service)

Data is limited (payload can be small)
Cloud initiated message can act as a pointer to direct devices to larger data

Web Role -> NS -> Device -> Ckoud/Service

There are a number of Push Notification Services available, e.g. For Windows 8: Windows Push Notification Service (WNS)

[Demo]

Platform Services

“Application Building Blocks”

  • Windows Azure Traffic Manager (Global Traffic Manager, load balance)
    • at the DNS level,
    • route request to closest PoP
  • Distributed In-Memory cache
  • Messaging (queues) e.g worker roles with async update
  • Identity
  • Windows Azure Media Services (cloud transcoding as a service)
  • Content Delivery Network (static content, geo-located)
  • On-premise access

Tools

  • NuGet Packages
  • iOS Tools (GitHub)
  • Android (Eclipse project)

Summary

Reviewed Storage, Identity and Application Blocks.  That is all.

Leave a comment

Your email address will not be published.

This site uses Akismet to reduce spam. Learn how your comment data is processed.