January 2015

Volume 30 Number 1

Azure Insider - BYOD Challenge: Connect Mobile Devices to the Enterprise

By Greg Oliver | January 2015

There are still many concerns surrounding the Bring Your Own Device (BYOD) movement in corporate environments and how Azure Mobile Services can help developers. A core value of Mobile Services is that it democratizes identity and lowers the cost and effort to provide secure access to protected corporate resources. In this article, We’ll take a closer look at what it takes to support more complex scenarios when connecting mobile applications to enterprise resources.

We’ll start by defining the identity stakeholders and look at the similarities and differences with respect to employees, trading partners and customers. We’ll also look at software architectures that provide secure connectivity for browser and mobile device users accessing on-premises services and sites. Later in the article, we’ll demonstrate these techniques using an iOS app that connects to a Mobile Services back end, as well as an on-premises service endpoint.

Not All Access Is Equal

There are several important goals of this effort. The first is to provide access to on-premises resources with a minimum of custom code or infrastructure changes, including existing network configurations. Another goal is to manage these usage scenarios to ensure control and visibility, while being agile and flexible.

Not all users who need access behind the corporate firewall are created equal. And not all data behind the corporate firewall needs the same level of protection. Some employees need greater access to protected information. Employees like field salespersons need access to the most up-to-date information on product prices and inventory levels. They may even need access to accounting data on their customers, such as recent payments on account. They probably don’t, however, need access to human resources applications.

Trading partners have their own specialized needs. Trusted business partners will frequently federate identity across an extranet. Trading partners typically manage their own identity infrastructure to authenticate users and will use “claims” to moderate access to a company’s protected resources. Thus, either the partner or the company will use trust policy to map the incoming claims to claims understood by a protected resource, such as an internal Web application.

There are two other less common identity stakeholders. Customers often need access to their account information, something like PayPal or Netflix. A prospect is effectively a potential customer. He might have given up credit card information, but hasn’t really bought anything yet. All these types of users share one common aspect: They all want to bring and use their iOS, Android and Windows Phone devices to work at the enterprise.

Enterprise Security Management

At least five software stacks play a role in securing mobile devices in the enterprise. Here, we’ll take a closer look at Hybrid Connections, Azure Service Bus, Azure Active Directory Application Proxy and Microsoft Azure API Management.

It would be simple to have employees present their credentials to Active Directory through a Web UI, get an access token and start working, but the world of identity is more nuanced and complex. The notion that “one size fits all” is simply not true. Employees are typically forced to use a corporate identity provider.

Most enterprises have brought identity in-house, typically leveraging Active Directory, which mostly exposes an LDAP-based protocol. In this new mobile, cloud-enabled world, enterprises need an HTTP-based communication protocol for mobile devices. Microsoft has created such an identity system in Azure called Azure Active Directory (Azure AD). One of the great features of Azure AD is that enterprises can sync identities to the cloud using directory synchronization. Read more about that process at bit.ly/1ztaB9Z.

There are a couple of other nice features in Azure AD. Azure AD provides the convenience of single sign-on (SSO). This lets an employee access protected resources over time without repeatedly being forced to log in and provide credentials. The access token is stored locally as a cookie on the employee’s device. You can limit access by using token expiration techniques.

Azure AD also supports OAuth 2.0, perhaps the most popular open standard for authentication. This provides client applications secure delegated access to server resources on behalf of a resource owner. Using OAuth 2.0, Azure AD can authenticate a user and issue either a SAML 2.0 or JWT token. Read more about how tokens work at bit.ly/1pDc0rg.

Trading Partners

The traditional way companies have managed authentication across each other’s IT infrastructures has been through federation trust. This involves establishing a trust between the federation services of the two companies (see Figure 1). This supported secure Web-based transactions with business partners. However, it’s not as straightforward as it sounds, and can indeed present challenges.

Figure 1 Traditional Identity Model for Active Directory Federation

The partner needs to set up a trust relationship between their Active Directory and the other enterprise’s Active Directory. This lets an employee from one company authenticate through their own Active Directory and then swap authentication tokens with the other company’s Active Directory in order to gain access to an app in the other network. This approach requires a lot of coordination and manual workflows for IT administrators.

Figure 2 depicts a more modern approach to identity management. Generally, a copy of employee identities are hosted in Azure, although some identities may reside in Azure alone. Maintenance is kept at a minimum because the original copy of most identities is managed on-premises. A background synchronization process keeps the cloud copy of identities fully synchronized. Users can connect directly to Azure AD in a datacenter in the cloud and then get redirected to the appropriate application.

Figure 2 A Modern Approach to Identity Management

For mobile app developers, you’ll find a number of libraries on GitHub you can use to take advantage of Azure AD (bit.ly/1qmeipz).

Android, iOS, the Microsoft .NET Framework, JavaScript, Node.js and more are all supported. For example, the iOS sample shows you how to obtain an interactive authorization code to work with a work account. You can tie this work account to an Active Directory server running in your datacenter or live completely in the cloud with Azure AD. On the back end, you could use either a REST-based Node.js API or .NET Web API.

Customer Access

You don’t usually think of customer-facing sites and services having access to protected company resources. However, this is more common than you think. For example, Wells Fargo might want to expose a customer’s financial data across the Web via a secure Web site or mobile app, while Netflix might want to provide secure access to protected resources such as current account balance or payment history. This becomes especially important for customers using mobile devices.

In some scenarios, it even makes sense to leverage social identity providers, such as Microsoft Account, Facebook, Google or Twitter. This approach was demonstrated in detail in the November Azure Insider article (msdn.microsoft.com/magazine/dn818496), in which we wrote a native iOS application that uses Twitter as the identity provider.

The assumption here is that anyone can download your app or access the Web site. There’s a publicly available service tier. Prospects typically have an unauthenticated experience, and see only publicly available information. Even in this case, there may be some need to access on-premises resources. Your service could provide an unauthenticated tier of service or respond to a set of default credentials.

Secure Connectivity Tools

Identity aside, there are several tools that can help securely connect users to resources in enterprise networks. One such example is Azure Service Bus Relay (see Figure 3), which provides an elegant way to facilitate access to protected resources. You can think of the Azure Service Bus Relay as a cloud-hosted service acting as a gatekeeper to broker the connection between a client and corporate resources. The Service Bus Relay is authenticated and only opens outbound ports. It supports Topics and Queues, as well, so you could implement a form of distributed messaging. You could even incorporate Event Hubs if you needed to ingest large amounts of events.

Figure 3 The Azure Service Bus Relay

The advantage of this approach is there are no configuration changes required to the on-premises networks. That includes provisioning users or changing firewall settings, because both the client and back-end service use outbound connectivity to port 80 or 443. In other words, no additional ports need to be opened to incoming traffic and no proxies are required.

Application Proxy Approach

The second approach to making protected resources available outside the firewall is to use the Azure AD Application Proxy service, currently in Preview. This provides secure access to an organization’s internal Web apps and services through HTTP and HTTPS Web protocols.

The big benefit of this approach is users can enjoy SSO and a native application experience and still use an unmanaged, non-domain-joined device. In a previous article, we discussed the concept of a “workplace join,” which is a lightweight version of a fully domain-joined device (bit.ly/1tE7dRR). This supports those BYOD scenarios where users want to retain control of their personal device.

Azure AD Application Proxy provides tight integration with Azure AD, supporting SSO, Software-as-a-Service and on-premises applications, multifactor authentication and device registration. The connector bridges the resource to the application proxy and, therefore, the mobile application. These connectors essentially route traffic and support redundancy, scale and multiple sites.

An Application Proxy provides a few advantages. First, you can implement fine-grained control at an application, device, user and location level. Existing client apps don’t need modification and the devices themselves don’t need to be modified. It also supports multifactor authentication (MFA), which can provide an extra level of protection for highly confidential resources. MFA provides several supporting services, like fraud alerts, IP whitelists, and mobile phone or SMS as a second authentication factor.

The third advantage of an Application Proxy is it provides isolation between cellular networks and on-premises networks. Back-end services are never directly exposed because the Application Proxy itself lives in Azure AD and the connector reaches out directly from the protected resource. Finally, an Application Proxy protects against denial-of-service attacks, giving you control over throttling, queuing and session management.

API Management

A third approach to providing access to protected resources is Azure API Management, which also behaves as a proxy to your on-premises resources. This lets you expose Web services implemented within your firewall to the outside world. To make this option work, you’ll need to make some modifications to your on-premises Web server, as well as create and configure an API in the Azure portal. You can author your API with either .NET Web API or Node.js.

First, we’ll consider authenticating with Azure API Management—basic authentication to provide outside access to an on-premises IIS-based Web server. The first step to enabling this scenario is to make some changes to your on-premises IIS Web server and enable basic authentication. Within IIS, you can choose the authorization icon and drill down to basic authentication to add a user. Azure API Management will access on-premises IIS with this user profile.

The next approach you can use with Azure API Management is shared secret authentication. This means the API Management proxy will need to store a secret key. It will place that key in the HTTP header before trying to connect to the on-premises back-end Web service. It should be no surprise the back-end Web service will need to pull the secret key from the HTTP header and process the authorization request.

You can implement shared secret authentication by going to the Azure Management Portal, navigating to the API Management section and selecting Policies from the menu. Here, you’ll add a policy, which is nothing more than a secret key sent to your on-premises Web server. The policy definition file that you’ll add is an XML document.

Hybrid Connections

The fourth and arguably simplest approach to granting access to protected resources is using Hybrid Connections (see Figure 4), a feature of the Azure BizTalk Services currently in Preview. Hybrid Connections leverages Service Bus Relay technology to create a simple, secure and effective connection between on-premises process and an Azure Mobile Services service or an Azure Web Sites site. You can use Hybrid Connections to connect to any on-premises resource that uses TCP or HTTP for connectivity, including databases and ERP solutions such as SQL, Oracle and SAP.

Figure 4 Microsoft Azure BizTalk Services—Hybrid Connections

A requirement for this is the on-premises process must be accessible via a static TCP port, such as SQL Server on port 1433. You can use any framework to connect to the resource, including Node.js, Java or the .NET Framework. Most of the configuration requirements of Service Bus Relay are abstracted away by Hybrid Connections. There are no required changes to the source code of the on-premises process.

To use Hybrid Connections, configure a small amount of metadata in the Azure Management Portal. Install an agent on the server that hosts your process (SQL Server, MySQL, your Web service and so on). There’s a Service Bus Relay connection under the covers, using an SAS key for authentication. You can rotate both service-side and client-side keys independently from within the portal. Because it uses Service Bus Relay, no incoming endpoints or proxies are required.

If you prefer more simplicity in your set up and developer efforts, Hybrid Connections might be your solution. Better yet, because it’s available in the free tier of Azure BizTalk Services, you can use it cost-effectively, only paying for egress bandwidth.

Now for a Demonstration

As promised, we’ll now demonstrate some of the techniques outlined here, using a native iOS app plus its AMS back end as the platform. We’ll add an on-premises Web service and an on-premises SQL Server using Hybrid Connections. In the interests of conserving space and utilizing already-existing resources, please refer to the AMS team’s tutorial at bit.ly/1mK1LQF. In the directions you’ll find branches to additional tutorial resources (bit.ly/1vFiPuv and bit.ly/1xLWuuF) to build out the complete solution, which consists of the following:

• A Web API back end installed as an AMS service and registered with an Azure AD tenant
• A native iOS app registered with the same Azure AD tenant
• Bi-directional linkage within the tenant between the Web API and the AMS service 

There are several steps that involve creating metadata in the Azure Management Portal, while others involve using native development tools (Visual Studio, Xcode, Android and more) to create the actual apps. When complete, you should have a working system that requires you to authenticate into your iOS app by entering Azure AD credentials. Then it will let you do CRUD operations on To Do data. Add the code in Figure 5 to the mobile service code.

Figure 5 Client Code Leverages Protected Resources via a Hybrid Connection

// Use the SQL Server connection
try
{
  SqlConnectionStringBuilder builder = new SqlConnectionStringBuilder();
  builder["Data Source"] = "myserver";
  builder["Integrated Security"] = false;
  builder["Initial Catalog"] = "mydb";
  builder["User ID"] = "greg";
  builder["Password"] = "S3cr3t";
  int count = 0;
  string query = "SELECT COUNT(*) FROM mytable";
  using (SqlConnection conn = new SqlConnection(builder.ConnectionString))
  using (SqlCommand cmd = new SqlCommand(query, conn))
  {
    conn.Open();
    cmd.CommandType = System.Data.CommandType.Text;
    count = Convert.ToInt32(cmd.ExecuteScalar());
  }
  string results = string.Format("Count of records in mytable is {0}", 
    count);
  Services.Log.Info(results);
}
catch (Exception ex)
{
  Services.Log.Error(ex.Message);
}
// Use the Web service connection
try
{
  const string URL = "https://mydevbox:31106/";
  HttpClient client = new HttpClient();
  client.BaseAddress = new Uri(URL);
  client.DefaultRequestHeaders.Accept.Clear();
  client.DefaultRequestHeaders.Accept.Add(
  new MediaTypeWithQualityHeaderValue("application/json"));
  string response = await client.GetStringAsync("api/values/5");
  Services.Log.Info("Accessing the web service succeeded.");
}
catch (Exception ex)
{
  Services.Log.Error(ex.InnerException.Message);
}

In the connection information for SQL Server and the addressing of the Web service (a simple template Web service), only the name of the Hybrid Connection is involved.

Wrapping Up

Identity is becoming increasingly important in the world of BYOD. Businesses are under increasing pressure to support mobile devices in the workplace. It’s made more complex by the fact that we live in a hybrid world. Key resources are located in the cloud and on-premises. Authentication may occur in the cloud or on-premises or both. Protected resources might include business apps, services running on-premises or cloud-hosted Web services. With so many variables, you need multiple flexible approaches.

For full details of this implementation, check the Go Live on Azure blog post at bit.ly/1rVbtCp, and for a Java-based treatment of the topic, bit.ly/1zW7XpZ.

Greg Oliver *joined the Microsoft Azure ISV organization in 2010. He spends most of his time helping companies with their migration plans and implementations. Most recently, he has been working with a popular consumer games company with their migration from a competing cloud provider. Prior to joining Microsoft, he was a technology partner in a startup company. *

Bruno Terkaly is a principal software engineer at Microsoft with the objective of enabling development of industry leading applications and services across devices. He’s responsible for driving the top cloud and mobile opportunities across the United States and beyond from a technology-enablement perspective. He helps partners bring their applications to market by providing architectural guidance and deep technical engagement during the ISV’s evaluation, development and deployment. He also works closely with the cloud and mobile engineering groups, providing feedback and influencing the roadmap.

Thanks to the following Microsoft technical expert for reviewing this article: Santosh Chandwani