Infosys | Microsoft

Listed below are the basic design considerations identified for the application:

1. Application must be accessible from any device and any location

2. Secure access to application resources using a federated identity and allowing users to reuse their existing credentials which they may have with other Identity providers such as Live, AD, OpenId etc.

3. Application should support multi-tenancy and have elastic scale to meet fluctuating workload demands
   

MYOC is a cloud application build on the Windows Azure platform. The above design considerations are satisfied by the Azure services platform and the .Net framework. Here is a pictorial representation of the MYOC solution:

MYOC Solution Architecture

At the core lies MYOC build on the Windows Azure platform, to provide poll functionality to a varied set of users ranging from the retail consumer to the Enterprise User. Polls can be made accessible over different devices such as PC, laptop, mobile, telephone etc.  At the same time the poll presented is context aware, with respect to the device on which the poll is being presented. Polls will be presented in a manner that is more suited to the device used by the user. For e.g., from a laptop or PC, the user will be presented a poll on SilverLight; from mobile, the Poll will be presented in plain HTML; if the user accesses the poll from a Telephone, the poll would be presented over IVR.

The earlier stated design considerations in this blog, have been addressed by identifying the following key areas:

Service Oriented Architecture

The application has been build on the principles of SOA, with access to the application functionality provided by REST based services over HTTP with the goals of having them to

1. Be easily consumed by any platform be it .NET, Java, mobile apps, widgets or any other which exists based on open standards
   

2. Be easily extendable to support additional devices for the future
   

3. Provide a development platform for other users to build poll application on MYOC
   

Having been build on top of Windows Azure, the ubiquity of this platform allows MYOC functionality to be accessible by any standard http-aware devices from any location which has internet access. Using the SOA design model achieved using REST we were able to provide users and developers with unified access on the MYOC platform across multiple delivery channels.

  MYOC Service Oriented Architecture Design

To read more on the way REST interfaces are implemented in MYOC, go here .

Federated access

MYOC has been designed to be extensible so as to support multiple identity providers such as Live, Open Id, Enterprise Ads, Custom Forms Authentication etc..The app can handle authentication and access control across these multiple identities from a single place. And this has been possible as the Authentication and Access control in MYOC has been managed separately on the cloud. This separation has been primarily achieved by using the Windows Identity Foundation (previously known as Geneva) and the .NET Service bus Access Control Service (ACS). The federation model allows users possessing separate identities to access this application in the same manner as they would experience with other apps supporting these identities. 

MYOC Access Control Design

From the above figure depicting a pictorial representation of the working model of ACS in which the user access rules is not maintained in the application code or some privately owned application repository. It will be maintained in a common repository of the Access Control Service in the form of claims. Every user (Requestor) accessing MYOC (Relying Party), once authenticated by their respective Identity providers will be provided a claim by ACS. Within the application, these claims are used by MYOC to decide the access privileges of any user. Separating the access control rules now allows architects to re-use claims across multiple applications and thus centrally managing and maintaining this repository.
Also access to the MYOC functionality is secured by the .NET Service Bus and the Windows Identity foundation. A detailed explanation on the federation process used in MYOC is available here.

SaaS Enabled

In addition to being Service oriented, a SaaS enabled application also needs to be multi-tenant and highly configurable. In MYOC, the current version, has been enabled to support multi-tenancy, leaving out configurability for a future version of the app. The various multi-tenant deployments models that can be supported by the application are represented below.

MYOC multi-tenancy models supported 

Multi-tenancy in MYOC is configured at both an application instance level and the data storage level.

Application Instance Multi-tenancy

Application instance level multi-tenancy is directly enabled and provided by the virtualized platform of Azure. Avoiding any user specific implementation in my code, I can deploy an application in either a shared model, by using the same web role instances for every user or in an isolated manner, by provisioning a new hosted instance for every customer who wishes an isolated model. 

Data storage Multi-tenancy

Multi-tenancy at the data level is what would need to be explicitly handled in the application design. The access and isolation of the customer data is configured based on the domain a particular user identity belongs. Two multi-tenancy schemas are possible in the storage aspects of the application - Shared data and Isolated data

Shared Data multi-tenancy model

In this model, the poll data created by the users will be stored in a common storage account and the data of a particular user is partitioned by their respective unique user id’s thus bringing in data isolation in a shared model. The application, based on the users identity, passes the data access request to the common storage. The application then accesses the data based on the users id which is the partition key identified,
The shared data schema is more suited for retail consumers, the likes of Live , Yahoo etc.., users, not warranting the need for any dedicated data isolation or meet any specific data security compliances. This model makes more efficient usage of the storage account as compared to the following isolated model but is perceived as less secure model to eliminate data privacy concerns

Isolated Data multi-tenancy model

In this model, the polling data will be persisted in a separate storage account and not the one used in the shared data model. Enterprises that are generally privy about their data prefer this model, wherein they get complete data isolation of the poll created by the enterprise users.
In this case the application, based on the users domain, route the data access request to a separate configured storage account. The separate account is mapped to the domain from which a user logs in. This is managed at the application level with the logic embedded in code. The model provides a more secure approach to reduce the data privacy concerns but at the same time lower storage utilization efficiency.

In the next blog I shall cover the technical architecture of the application