Securing Windows Azure Applications for Mobile Devices
Author: Ralph Squillace
This topic describes the security issues involved with building smartphone or device applications in general, what security approaches are available when a mobile device application collaborates with services hosted on Windows Azure, and high-level discussions of approaches to security on Windows Phone as well as other devices. In addition, a dense set of links to more information is provided, both for Windows Phone development but also for other devices and general application security issues.
|It is out of scope of this topic to address basic security practices such as STRIDE approaches to threat modeling. It is also out of scope of this topic to describe in depth specific approaches to security practices on each major smartphone or internet enabled device or chip. (Instead, links to specific platform approaches are provided in the next section for more information.)|
A Note on General Security Information for Devices
Let’s be clear: Building mobile apps on Windows Azure is structurally similar to building client-service applications anywhere, including web sites for which the clients are browsers. (Web sites are web services that return HTML for an HTTP request, so really, it’s important to realize that all Windows Azure applications are Windows Azure Hosted Services.) At the highest level, the following graphic indicates the structural identity involved.
For this structure, it should be clear that handling security means:
Identifying and implementing how your Windows Azure application handles security in general
Making sure that clients work with the security implementation of your Windows Azure application
Applying the correct security approach for your particular client device.
Mobile Device Resources
The three main issues on mobile devices are connecting securely using HTTPS, interacting with the Access Control Service to obtain a token to access the service, and properly obtaining and storing securely on the device any credentials used to authenticate with the service. Each platform has different ways to perform each behavior; but your application should have well-thought out solutions for each of these steps.
The Microsoft Developer Platform Evangelism team for Windows Azure has built toolkits for each of the mobile device platforms discussed in this article that make using HTTPS and obtaining an access token from ACS straightforward. (For more information, see your mobile platform in the following sections.)
It is the last task – securely storing user or application credentials on the device -- that requires careful analysis and some mastery of a particular platform. Any credentials stored on the device, even encrypted, are only as secure as the complexity and location of the keys used for the encryption itself. Therefore, it is strongly recommended that you adopt a regime that makes it highly unlikely that malicious applications can obtain the original encryption keys. Each platform has documentation that provides guidance, and the general problem is dealt with in a sample proxy service described in the Windows Azure Toolkit for Windows Phone.
If you’re already a Windows Phone developer and just want to build Windows Phone application that works with Windows Azure services, see the Windows Azure Toolkit for Windows Phone and Using Windows Phone with Windows Azure. Together, if you’re already familiar with the phone you can use these starter kits to begin your Windows Phone application integration with the Access Control Service (ACS), the critical authentication service to access a Windows Azure application.
|There are scenarios in which the Windows Azure service you want to use does not use ACS, and for these services, you must read the documentation or contact the service owner to use the service securely. The most common scenario is a service that uses username/password authentication over HTTPS. This can be managed using ACS, but the service developers may not have chosen to do so.|
For Windows Phone, the place to start for device and development security is Security for Windows Phone. Because Windows Azure applications that work with mobile devices are above all providers of web services, the single most important topics are:
If you’re an iOS developer already and just want to build an application that works with Windows Azure services from an iOS device, start with the Windows Azure Toolkit for iOS.
For iOS (Apple) applications, the relevant documentation to start with is iOS: Understanding data protection, which mentions how to turn the pin code on, and Security Starting Point, which is the starting point for Apple security developer documentation, and Introduction to Security Overview, which contains the most complete list of security APIs, concepts, and samples.
For Android, the Android security index is one of the better places to start understanding what that device and operating system can do.
Overview of Security for Windows Azure Hosted Services
Distributed applications have (at least) two participants (that is, a service and a client of that service), each of which must work together to protect users and their data, whether at rest in the service application, at rest in the mobile application, or in flight between the two. It should go without saying – but here it is just to make sure – that the service hosted in Windows Azure must have good threat modeling just as any other service oriented application ought. That said, the focuses of the remainder of this article are:
Authentication is the process of establishing a claimed identity; authorization is the process of deciding and controlling the resources to which that identity has access. In a Windows Azure application – as in a distributed application more generally – you should authenticate by:
Doing any sensitive work either after employing the Windows Azure Access Control Service (ACS) to manage your credential handling with that service, or
Implementing your own authentication component or service
Sometimes these can be the same thing. If you are using a feature of Windows Azure Service Bus, for example, you must authenticate with ACS, but once you do, the claims in your authenticated token are used to authorize your access to the feature. For more information, see Service Bus Authentication and Authorization with the Access Control Service.
For your own application services, however, ACS does not currently offer authorization. Even if it did, many applications have good reasons to implement their own security services. Banks, for example, or any other privacy related service may offer as part of their value to the customer a local, proprietary, authentication and authorization services as part of their specific value to their customers – they may not even be hosted in any cloud development platform like Windows Azure. In this case, implementing your own authentication database (membership roles in ASP.NET or some other) is one approach, and another is implementing your own security token service (STS) that can be federated with ACS.
Precisely how you use ACS from your Windows Azure application depends upon the application. Typically, mobile devices interact with Windows Azure applications by requesting web pages from a web site or by making requests of web services. For more information about the first, see Web Applications and ACS and Securing Web Applications with ACS. You can find a good step-by-step example using ASP.NET at How to Authenticate Web Users with Windows Azure Access Control Service.
For more information about using ACS with web services, see Securing Web Services with ACS.
If you want to use ACS to handle your own password system, you can build your own STS, or you can use a starter example like the thinktecture Identity Server as a basis for your own.
|When you build your own STS, you are taking your application’s security into your own hands. There are often very good reasons to do this, as some of the example cases above suggest. However, taking this responsibility into your own hands comes with all the upsides and downsides of any responsible development task: You get the benefits of complete control over the design and implementation of your own application security, but with the responsibility of testing very heavily to make sure you have done it correctly. Your customers’ security or application data is on the line.|
Unless you implement your own authentication system or use one in another system or platform, it is recommended that you consider a trusted system approach, in which you authenticate the user and access the resources they are authorized to use on their behalf, rather than using impersonation or delegation to act as them. The result is an application that authenticates at the client interaction boundary – a web site or web service – and assigns an id, internally, to that session and user. Internally, your Windows Azure application then handles resource access for that particular user id based on the information in its own authorization service.
Active Directory Federation Services 2.0
If you have a Windows domain with Active Directory, you can use Active Directly Federation Services (ADFS) as an STS to provide domain credentials to external users. In addition – and most importantly for mobile device applications, you can federate ADFS with ACS to create a web service for devices to connect to Windows Azure applications with domain credentials you control. Doing so makes it possible to expose securely internal business applications to almost any mobile device, provided it has the ability to send and receive HTTPS requests and responses. For a direct example of how to do this, see How To: Configure AD FS 2.0 as an Identity Provider.
You can also implement your own STS in Windows Azure for web sites by using the Windows Identity Foundation. For specific examples, see ASP.NET Security Token Service Web Siteand WCF Security Token Service.
Typically, it is said that there are two parts to encryption, encrypting the data while it’s at rest – that is, stored on the device itself, whether it’s a username, password, or other data – or while it’s in flight – that is, when it is being transferred between the service and the device. In some cases, it’s helpful to note that really encryption is about data in flight, always; data stored temporarily is really data that is being sent to the future, rather than to a different location or receiver.
In almost all cases, using HTTPS for request to and responses from your web service or web site is sufficient. Almost every mobile device can participate with your Windows Azure hosted service. For any sensitive information, it may also be necessary to encrypt and decrypt data internally. Doing so, however, runs into the same problem that exists on mobile devices: the encryption keys must be stored in a place that is itself secure from attack, the encryption work you do will be useless.