Skip to main content


Designing a Cloud-Based Mobile Application for Compliance

Last Reviewed On: October 31, 2013

Author: Dan Griffin, Microsoft MVP - Enterprise Security and Tom Jones, Software Architect, JW Secure

Imagine that you need to develop a mobile dashboard for patient healthcare data. The dashboard must address the following requirements:

  • Allow in-house healthcare providers to access an always-current summary of the patient history. Healthcare providers must be able to view this summary using a standard smartphone.
  • Allow external healthcare providers, such as a team of radiologists in India, to access patient data when they are interpreting imagery data in support of a 24-hour productivity cycle.
  • Be as close as possible to Health Insurance Portability and Accountability Act (HIPAA) compliance, including meeting requirements for auditing and data encryption.

These requirements present plenty of challenges. While sharing the data externally necessitates federation and a cloud-based solution, compliance and cloud computing don’t necessarily happily coexist. In addition, medical imagery files are large. Finally, healthcare providers are often wary of adopting new technologies in the workplace since some past implementations might have slowed them down.

However, for rapid development and deployment of a mobile application using federated authentication, the cloud is often still the fastest and most cost-effective option available. For an independent software vendor (ISV), being the first-to-market may be crucial for the success of the solution. For an internal IT team, there is inexorable pressure to cut costs. However, the flexibility of the cloud makes it easier to deliver a new and compelling application online, on schedule, and cost-effectively.

Let’s analyze how this solution can be deployed securely and successfully to the cloud. For reference, here’s an architecture diagram that identifies the major data flows:

Application components

Figure 1. Application components

This figure shows the following data flows:

  1. The user launches the application.
  2. In order to perform authentication, the application server redirects the client to a Security Token Service (STS), such as Windows Azure AppFabric Access Control Service (ACS).
  3. ACS, in turn, redirects the user to the appropriate identity provider. In this case, that is the Active Directory Federation Services (ADFS) server operated by the user’s employer.
  4. Once authentication and authorization are successfully completed, the user may access the requested application data. The data access is audited by the application server.

Note: The Identity Provider #2 server in the diagram is included to illustrate how an external team (the off-site radiology team in India, for example) could securely access the imagery data as well. In this instance, the accounts for the off-site team are stored in Active Directory. See the Authentication section below for more details about this scenario.

In this article:


In regard to technical security requirements, the main issue to consider is compliance. For example, we know that patient data has to be encrypted, that we must put controls in place to prevent accidental disclosure, and that we need to audit access.


Users will sign into the mobile application with a user name and password. To mitigate the risk of stolen or shared passwords, it is be ideal to use a multifactor authentication method, such as user name/password and radio frequency (RFID) card combination. However, while the medical field has begun to adopt RFID cards, smartphones generally do not include RFID readers.

One-time passwords (OTPs) are another multifactor authentication option. Some organizations have become concerned about the security of OTPs after the high-profile attacks against RSA Data Security and some of its customers. However, we still consider an OTP solution an excellent choice for multifactor authentication, and it is vastly preferable to static passwords.

Because this scenario involves both on- and off-premises users (for example, the off-site radiology team in India), we must also support federation of the user accounts. We might expect that the on-premises personnel have accounts in Active Directory. The outsourced radiology team will have its own account store, and that store might not be Active Directory–based. Some organizations will choose to create accounts in Active Directory for the outsourced team, while others will choose to trust the outsourced team to be authenticated using its own systems. Either way, in order to expose the on-premises Active Directory accounts to the cloud, we should use Active Directory Federation Services. There might be one or two Active Directory Federation Services servers involved in the scenario—one if the outsourced team is not using Active Directory and two if it is. Identity claims issued by Active Directory Federation Services can be processed either directly by the application service or by a claims mapping service such as Windows Azure AppFabric Access Control Service.

Authorization and Auditing

The biggest complaint of IT organizations as they transition services to the cloud is loss of control. Claims-based authorization is an under-utilized technique that is relevant in this context because fine-grained control is its primary benefit. One example of claims-based authorization is apparent in the context of the mobile imagery application: If the user is the patient’s recorded doctor, he or she can view that patient’s imagery data.

Designing the authorization scheme to be used by the mobile imagery application will first entail determining which account stores will be trusted to authenticate users. Secondly, it will involve establishing requirements about the claims that must be issued by those identity providers in order for authorization decisions to be made. For example, the application may be dependent on a Title claim, with possible values including Doctor and Nurse. We recommend the use of claims mapping for simplifying this task.

Compliance auditing requirements are another great example of how claims-based authorization can be used to improve control. We will configure the medical imaging application to require the user to present trusted claims not only about the user’s account name and title, as described above, but also about the client device. In the case of the mobile device, we will gather information about the device type, unique device ID, firmware version, and even what other user applications are installed. If the user has installed a mobile application determined to be malware, policy can be set in the medical application to strictly audit access or even deny access in order to help ensure that sensitive patient data cannot be compromised by the suspected or known malware.

In fact, more and more information about the health of the client device (in this case, a smartphone) is becoming available. This important and positive trend allows the IT department to effectively offer wider access to data with lower risk. If the server can trust the client to accurately report on its system state, the server can also decide whether the client is sufficiently secure to receive sensitive data. This capability, combined with strong user authentication, allows the IT manager to help ensure that only the right people have access to the right data from the right devices, and still provide access to the users from anywhere in the world. For more information about tracking client health claims, please read about secure boot and remote attestation on the JW Secure website.

In summary, for each call into the application server, a range of information about the user and device is available for auditing, as well as for making granular authorization decisions.


Several options are available for encrypted data stored in the cloud. The main determining factor in evaluating those options is to decide whether plaintext (unencrypted) data may ever reside in the cloud, even if only briefly. Suppose, for example, that for our mobile imagery example we use a typical three-tier application architecture. The first tier is the mobile device, the second tier is an application server where business logic is implemented, and the third tier is where the data is stored. If the application server resides in the cloud, then there will inevitably be unencrypted data exposed to the cloud since the data must be in plaintext form in order for the application to display it. That’s true even if the third tier uses encryption or is stored on-premises.

That question--where to host the application tier if sensitive data is in play--is one of the single toughest architectural issues the IT manager faces when it comes to realizing the cost savings and nimbleness offered by cloud computing.

On the one hand, exceeding the requirements of compliance rarely makes good business sense, and in many situations, the industry standard appears to be to overlook this issue: As long as the data isn’t persisted or transmitted in unencrypted form, it’s okay for it to exist temporarily in plaintext on the application tier (even though “temporary” can be tough to define, due to data caching, swap files, etc.).

On the other hand, there are plenty of examples of data that should never touch the cloud in plaintext form—highly sensitive or strategic business information, classified government documents, etc. Therefore, it is important to note that cloud computing benefits can still be realized in those situations. Using an on-premises data encryption proxy, the organization can take advantage of cloud storage while still ensuring that plaintext data never touches the cloud.

For more information about encrypting data on-premises, read about cloud data encryption on the JW Secure website.


Although meeting HIPAA requirements with a usable mobile application can be daunting, the tools for doing so in a scalable and cost-effective manner are available. Claims-based authentication provides granularity and control, even in an environment—the cloud—in which control is generally thought to be lacking. Finally, architecture and hosting decisions can be geared to achieve the desired tradeoffs among data encryption, scalability, and costs.

More information about designing cloud-based healthcare solutions is available in Transforming Care Delivery with Windows Azure.

About the Authors

Dan Griffin Dan Griffin is the founder of JW Secure, Inc., a software security consultancy based in Seattle. He has published several articles on Windows security software development and is a frequent conference speaker and security blogger. You can also follow him on Twitter.

Tom Jones is a software architect and author specializing in security, reliability and usability for networked solutions for financial and other critical cloud-based enterprises. His innovations in security span a full range from mandatory integrity to encrypting modems.

Microsoft Security Newsletter

Sign up for a free monthly roundup of security news, bulletins, and guidance for IT pros and developers.