Authentication on Windows Azure using security certificates


Abstract:

Security is a key factor when moving/migrating applications to and on open/global platforms. Now cloud computing is becoming a hot spot for enterprises and with a majority of enterprises moving and planning to move to the cloud , application security has evolved as key challenge.

Though application security is a widely debated topic eventually it is about gaining access to the application resources in other words it abstracts to authentication and authorization. There are different ways of achieving it and this article intends to talk about how application security can be implemented for an application hosted on Microsoft Windows Azure given to the fact that the users still do not have access to the Registry/System Security certificate Store on Windows Azure.

Certificate based authentication is one of the most commonly used / required mode of authentication in the web world. This article will talk about a work around describing how to implement certificate based authentication using the any version of Windows Azure released till date.

Introduction

Application Security though a known area can pose a great challenge especially when we talk about applications on the cloud. Many existing applications would have embraced different forms of authentication mechanisms and certificate based authentication is for sure one  of the most commonly used means of authenticating clients through a trusted channel. As a preface to the content below we all understand that the Microsoft cloud enthusiasts have been playing around using the CTP versions  as well as Windows Azure V1(Nov 2009 release). It is evident that the users would be keen to explore the certificate based authentication on Windows Azure and the content below is an outcome of such an experiment.

What If.....

What if Windows Azure did not provide the users access to the certificate stores on the cloud? , we would have a lot of worried customers who have implemented certificate based authentication in their current applications and would have refrained from moving to Windows Azure considering this lack as a security lapse. Also the current version of Windows Azure supports a role specific certificate upload and limits the certificate count to a maximum of two per role. What if this restriction still remains in the future versions? What if Windows Azure does not support other certificate formats besides .cer which is the only current supported format.
Description

Microsoft Windows Azure as on date being an evolving cloud platform is still in a phase of adding features with further releases. For those who would want to implement a certificate based authentication will have to wait till Microsoft provides a concrete way of accessing the certificate store on its data center severs. We all understand that the strength of Windows Azure being minimum maintenance overhead on its customers and does not emulate the virtual box offering of other cloud providers in the market.

Our experiment had a need to showcase the usage of an X509 security certificate for authentication on Windows Azure. Ideally as we know it would require a certificate store access both on the client and the sever side for the same, the latter of which is currently not supported on Windows Azure. The diagram below depicts an overview of our strategy to implement the same.

1.gif 

Step 1:

The first step was to figure out a way to store the security certificate on the cloud (Windows Azure). The best probable way to do this at the moment is to build a  tool which would enable the user to upload a x509 certificate with predefined metadata on to a blob encapsulated with in a private container in a encrypted format. This is usually a onetime activity unless you want to change the security certificate.

Step 2:

Assuming the x509 certificate has been installed on the client machine we will need to fetch the respective certificate and extract the required metadata and have it ready for comparing it with the Meta data on the server side.

Step 3:

Now fetch the x509 certificate stored in the blob on Windows Azure in a private container. This can be a REST based call to make things even simpler and faster. We can either extract the required metadata in the cloud environment and pass only the required metadata back to the client which is a recommended way to do it as it would save us from taking extra precautions to secure the certificate over the  transport channel (though all calls to Azure are made through secure channels).

Step 4:

Decrypt  the server metadata fetched from the blob and compare it with the client certificate meta data and conclude if the client was a valid user or not.

The strategy above might sound like just another mode of custom authentication but yet offers certain unique advantages as listed below:
  • Security certificates are less prone to hacks and provide a secure encapsulated way of storing authentication tokens.
  • Security certificates provide us the liberty to include custom attributes and in a form we choose to include them.
  • Since access to local security stores on client require administrative access it serves as a caveat for unwanted users to access the same which is added security.
  • Additional encryption of security certificate attributes will make the data even secure and virtually fool proof.
  • A Single certificate would suffice for the whole process.
  • Different forms of security certificates (cert, pfx etc) can be used for the process.
  • Using this approach will overcome the limitation of using only a max of two security certificates per role as is the case in Windows Azure today.
Besides involving the security certificates for the above process the same can be used for securing the Restful call made to the cloud to ensure that the calls are being made from a valid client. The security certificate public and private keys can also be used in place of the custom metadata. 

Recommendations

It is important that additional custom attributes are included in the security certificate meta data and these are encrypted and stored and shall be decrypted after the meta data passes through the transport channel. More than one metadata attributes with different encryption formats  would make the data even more secure. It is also recommended that two levels of decryption one on the cloud and another at the client level can be used for added security.

Conclusion:

Security Certificates have existed as a very popular and trusted means of authentication and a lot of legacy/existing web applications use these for securing access to their applications. It is important that alternative mechanisms of using these certificates when these legacy applications are migrated to Windows Azure exist so that the customers know that application security using certificates is no more a challenge using Microsoft Azure.