Reader small image

You're reading from  Learning Microsoft Azure

Product typeBook
Published inOct 2014
PublisherPackt
ISBN-139781782173373
Edition1st Edition
Tools
Right arrow
Authors (2):
Geoff Webber Cross
Geoff Webber Cross
author image
Geoff Webber Cross

Geoff Webber-Cross has over 10 years' experience in the software industry, working in manufacturing, electronics, and other engineering disciplines. He has experience of building enterprise and smaller .NET systems on Azure and other platforms. He also has commercial and personal experience of developing Windows 8 and Windows Phone applications. He has authored Learning Windows Azure Mobile Services for Windows 8 and Windows Phone 8, Packt Publishing.
Read more about Geoff Webber Cross

Geoff Webber-Cross
Geoff Webber-Cross
author image
Geoff Webber-Cross

Geoff Webber-Cross has over 16 years' software development experience, working in a variety of sectors on Windows, web, and mobile applications. He has worked on XAML/MVVM applications since the days of Silverlight and Windows Phone 7 and has been building Xamarin apps commercially for a number of years. Geoff is also the author of two books for Packt: Learning Microsoft Azure and Learning Windows Azure Mobile Services for Windows 8 and Windows Phone 8.
Read more about Geoff Webber-Cross

View More author details
Right arrow

Chapter 10. Web API and Client Integration

In this chapter, we'll create an on-premise production management client Windows application allowing manufacturing staff to view and update order and batch data and a web service to access data in the production SQL database and send order updates to the Service Bus topic.

The site's main feature is an ASP.NET Web API 2 HTTP service that allows the clients to read order and batch data. The site will also host a SignalR (http://signalr.net/) hub that allows the client to update order and batch statuses and have the changes broadcast to all the on-premise clients to keep them synchronized in real time. Both the Web API and SignalR hubs will use the Azure Active Directory authentication.

We'll cover the following topics in this chapter:

  • Introducing a Web API

  • Introducing SignalR

  • Building a Web API service

  • Creating a SignalR hub

  • Publishing a Web API

  • Modifying the Web API AD manifest

  • Adding a client application to AD

  • Building a client application

Introducing a Web API


Using web services with client applications is common practice in many systems, as it allows clients to interact with data sources and other resources indirectly, allowing greater control over security and also allowing us to present data to applications in an application-domain friendly format.

The Web API (currently Version 2) is an ASP.NET framework for building RESTful HTTP web services (http://en.wikipedia.org/wiki/Representational_state_transfer) for a wide range of client applications, including websites, desktop applications, and mobile applications (although Azure also offers dedicated mobile services that we'll look at in the next chapter). A Web API is simple to implement compared to other web service technologies such as WCF, which is designed for SOAP and requires complicated configuration. A Web API is similar to MVC, where we have controllers with HTTP methods routed to actions, but where MVC is used to build websites that interact with a web browser and...

Introducing SignalR


SignalR is a library for .NET developers to help build real-time web-connected applications. SignalR makes use of WebSockets (http://en.wikipedia.org/wiki/WebSocket) where available, which provide duplex (two-way) communications over TCP sockets, allowing clients to send data to a server; but more importantly, it allows the server to push data back to the client, which means that clients don't need to continually poll the server for updates.

SignalR can have issues with scalability when deployed on load-balanced web servers because clients will have a connection to a single website instance and will not receive messages from other instances, which means that we end up with multiple hubs rather than just one.

There are a number of solutions to deal with scalability with SignalR using a backplane; where each hub forwards messages to the backplane rather than directly to the client, the backplane then updates all hub instances, which then forwards the message to the client...

Building a Web API service


We'll create a new web project for the production system that hosts the Web API HTTP service and the SignalR hub. Since we already have Azure AD authentication in place across the other internal systems, we'll configure this website to use Azure AD authentication, too.

If you've not already done so, read the Adding Azure AD single sign-on to a website section in Chapter 5, Building Azure MVC Websites, which covers creating an Azure AD, which is a prerequisite to creating a website with Azure AD integration.

Creating a Web API project

In the following procedure, we'll create a web project in Visual Studio with a Web API template and configure it to use Azure AD authentication:

  1. Add a new web project to your solution, I've called mine ManagementWebApi, select the Web API template and make sure Host in the cloud is checked:

  2. Click on Change Authentication, then select Organizational Accounts, fill in the Azure AD Domain field, and click on OK:

  3. Sign in using the new AD user...

Creating a SignalR hub


We'll implement a SignalR hub to allow clients to update order and batch statuses as they are changed by a user, and we'll receive updates from other clients in the system as they are updated by other users. Create the hub in the following procedure:

  1. Enter the following command into the NuGet Package Manager Console to install the Microsoft.AspNet.SignalR package:

    Install-Package Microsoft.AspNet.SignalR
    
  2. Enter the following command into the NuGet Package Manager Console to install the Microsoft.AspNet.SignalR.ServiceBus package:

    Install-Package Microsoft.AspNet.SignalR.ServiceBus
    
  3. Finally, enter the following command to install the windowsazure.servicebus package (do this at last because the Microsoft.AspNet.SignalR command installs its own version, which might not be compatible with partitioned brokered messages):

    install-package windowsazure.servicebus
    
  4. Modify the Microsoft.ServiceBus.ConnectionString app setting, which was added by the Microsoft.AspNet.SignalR.ServiceBus...

Publishing a Web API


We can publish a Web API straight to the website that was provisioned when we created it using the normal website publish procedure; however, we need to pay particular attention to the publish settings:

Check Enable Organizational Authentication, enter the AD tenant Domain name, make sure to set the database connection string of the Azure database, and check Use this connection string at runtime (update destination web.config).

When we publish, we need to enter our AD tenant login credentials:

When the publish process is complete, we'll see our website has been created, but we also see a new application appear in the AD tenant workspace APPLICATIONS tab:

The ida:Audience setting in the Web.config file will also be updated to have the ID of our new Azure Web API application.

Modifying the Web API AD manifest


Before we create an AD application for our client, we need to modify the manifest of the local and Azure ManagementWebApi (my Azure application is called webapp-azurebakeryproduction.azurewebsites.net) applications so that other applications can be given permission to access them using the AD authorization. We'll do this in the following procedure:

  1. Go to MANAGE MANIFEST | Download Manifest on the toolbar for the AD application in the portal:

  2. Open the downloaded json manifest file; the start should look something like this:

    {
      "appId": "0a2141c3-566f-4d52-98c6-9cb249224868",
      "appMetadata": null,
      "appPermissions": [],
      "availableToOtherTenants": false,
      "displayName": "ManagementWebApi",
      "errorUrl": null,
      "homepage": "https://localhost:44303/",
      "identifierUris": [
        "https://azurebakery.onmicrosoft.com/ManagementWebApi"
      ],
  3. Replace the empty "appPermissions": [] section with the following code, and save the file:

    "appPermissions": [
        {
         ...

Adding a client application to AD


Before we can connect to the Web API from our client application, we need to add it to our Azure AD with permissions to access the Web API application. We'll do this in the following procedure:

  1. Navigate to the AD workspace in the Azure portal.

  2. Click on ADD on the APPLICATIONS toolbar of our Azure Bakery tenant:

  3. Then, select Add an application my organization is developing:

  4. Enter the application NAME, select NATIVE CLIENT APPLICATION (the other option is for web applications), and click on the next arrow:

  5. Next, enter a value for REDIRECT URI (this just needs to be a valid URI for the redirect after the OAuth2 request and is not used in this implementation), and click on the tick button to complete:

  6. Now, we need to add permission to ManagementWebApi, so scroll to the permissions to other applications section at the bottom of the CONFIGURATION tab and add a new permission for ManagementWebApi, which should now appear in the list after our manifest modification. Now...

Building a client application


For the client application, we'll create a WPF client application to display batches and orders and allow us to change their state. We'll use MVVM Light again, like we did for the message simulator we created in the sales solution, to help us implement a neat MVVM pattern. We'll create a number of data services to get data from the API using Azure AD authentication.

Preparing the WPF project

We'll create a WPF application and install NuGet packages for MVVM Light, JSON.NET, and Azure AD authentication in the following procedure (for the Express version of Visual Studio, you'll need Visual Studio Express for desktops):

  1. Add a WPF project to the solution called ManagementApplication.

  2. In the NuGet Package Manager Console, enter the following command to install MVVM Light:

    install-package mvvmlight
    
  3. Now, enter the following command to install the Microsoft.IdentityModel.Clients.ActiveDirectory package:

    install-package Microsoft.IdentityModel.Clients.ActiveDirectory
    
  4. Now...

Summary


We covered a lot of topics in this chapter. Further, we explored providing a unified authentication system across the whole solution using Azure AD. We learned how to use a Web API to enable the production management Windows client application to access data from our production database and a SignalR hub to handle order and batch changes, keeping all clients updated and messaging the Service Bus topic.

The next chapter is the last chapter, where we will build applications before we start looking at preparing our systems before getting into production. We'll integrate a Windows Phone application into the sales system with push notifications and the Azure notifications hub. We'll also build a Windows Store application for the distribution business unit.

Questions


  1. Why is a web service particularly important when using SQL Azure Database?

  2. What is the problem with implementing SignalR in load-balanced websites?

  3. What solution can we use to solve this problem (as known from the preceding answer)?

  4. How can we enforce authorization in a controller?

  5. What techniques can we use to test a Web API service without writing any code?

  6. What is the hub SignalR URL?

  7. How do we enforce authorization in a SignalR hub?

  8. What does the Enable Organizational Authentication setting achieve during publishing?

  9. Why must the appPermissions section of Web API AD application's manifest be modified?

  10. In the client application's config, what are the ida:Audience ida:ClientID settings?

  11. If a user's authentication token has expired, what can be done to authenticate the users without them logging in again?

  12. How does a client call a SignalR hub method, and how can we tell if it was successful?

Answers


  1. SQL Azure only supports SQL authentication, which means that the client application needs access to the login details, which can pose a security risk.

  2. SignalR clients maintain connections to a single hub, which means that they will not send data to or receive data from other hub instances.

  3. Implement a backplane system such as Azure Service Bus to keep hubs updated in real time.

  4. Use the Authorize attribute at the controller or individual action level.

  5. If we temporarily remove the Authorize attribute, we can use the browser to make HTTP GET requests or a tool such as Fiddler or cURL to make other requests.

  6. The hub SignalR URL is api/signalr.

  7. We use the same Authorize attribute.

  8. An AD application will be provisioned for the new site and the site's Web.config file will be updated with the new ida:Audience ID.

  9. Client applications need to be given permission to access them.

  10. The ida:Audience ID is the ID of the target application, that is, the Web API, and ida:ClientID is the ID of the client application...

lock icon
The rest of the chapter is locked
You have been reading a chapter from
Learning Microsoft Azure
Published in: Oct 2014Publisher: PacktISBN-13: 9781782173373
Register for a free Packt account to unlock a world of extra content!
A free Packt account unlocks extra newsletters, articles, discounted offers, and much more. Start advancing your knowledge today.
undefined
Unlock this book and the full library FREE for 7 days
Get unlimited access to 7000+ expert-authored eBooks and videos courses covering every tech area you can think of
Renews at AU $19.99/month. Cancel anytime

Authors (2)

author image
Geoff Webber Cross

Geoff Webber-Cross has over 10 years' experience in the software industry, working in manufacturing, electronics, and other engineering disciplines. He has experience of building enterprise and smaller .NET systems on Azure and other platforms. He also has commercial and personal experience of developing Windows 8 and Windows Phone applications. He has authored Learning Windows Azure Mobile Services for Windows 8 and Windows Phone 8, Packt Publishing.
Read more about Geoff Webber Cross

author image
Geoff Webber-Cross

Geoff Webber-Cross has over 16 years' software development experience, working in a variety of sectors on Windows, web, and mobile applications. He has worked on XAML/MVVM applications since the days of Silverlight and Windows Phone 7 and has been building Xamarin apps commercially for a number of years. Geoff is also the author of two books for Packt: Learning Microsoft Azure and Learning Windows Azure Mobile Services for Windows 8 and Windows Phone 8.
Read more about Geoff Webber-Cross