Cloud Computing and Software-as-a-Service

Microsoft’s Windows Azure runs Windows applications and stores advanced applications, services and data in the cloud. This baseline understanding of Windows Azure, coupled with the practicality of using computers in the cloud makes leveraging the acres of Internet-accessible servers on offer today an obvious choice. Especially when the alternate option of buying and maintaining your own space in data centers and hardware deployed to those data centers can quickly become costly. For some applications, both code and data might live in the cloud, where the systems they use are managed and maintained by someone else. On-premise applications—which run inside an organization—might store data in the cloud or rely on other cloud infrastructure services. Ultimately, making use of the cloud’s capabilities provides a variety of advantages.

Windows Azure applications and on-premises applications can access the Windows Azure storage service using a REST-ful approach. The storage service allows storing binary large objects (blobs), provides queues for communication between components of Windows Azure application, and also offers a form of tables with a simple query language. The Windows Azure platform also provides SQL Azure for applications that need traditional relational storage. An application using the Windows Azure platform is free to use any combination of these storage options.

One obvious need between applications hosted in the cloud and hosted on-premise is communication between applications. Windows Azure AppFabric provides a Service Bus for bi-directional application connectivity and Access Control for federated claims-based access control.

Service Bus for Azure AppFabric

The primary feature of the Service Bus is message “relaying” to and from the Windows Azure cloud to your software running on-premise, bypassing any firewalls, network address translation (NAT) or other network obstacles. The Service Bus can also help negotiate direct connections between applications. Meanwhile, the Access Control feature provides a claims-based access control mechanism for applications, making federation easier to tackle and allowing your applications to trust identities provided by other systems.

A .NET developer SDK is available that simplifies integrating these services into your on-premises .NET applications. The SDK integrates seamlessly with Windows Communication Foundation (WCF) and other Microsoft technologies to build on pre-existing skill sets as much as possible. These SDKs have been designed to provide a first-class .NET developer experience, but it is important to point out that they each provide interfaces based on industry standard protocols. Thus, making it possible for applications running on any platform to integrate with them through REST, SOAP and WS-protocols.

SDKs for Java and Ruby are currently available for download. Combining them with the underlying Windows Azure platform service produces a powerful, cloud-based environment for developers.

Access Control for the Azure AppFabric

Over the last decade, the industry has been moving toward an identity solution based on claims. A claims-based identity model allows the common features of authentication and authorization to be factored out of your code, at which point such logic can then be centralized into external services that are written and maintained by subject matter experts in security and identity. This is beneficial to all parties involved.

Access Control is a cloud-based service that does exactly that. Rather than writing your own customer user account and role database, customers can let AC orchestrate the authentication and most of the user authorization. With a single code base in your application, customers can authorize access to both enterprise clients and simple clients. Enterprise clients can leverage ADFS V2 to allow users to authenticate using their Active Directory logon credentials, while simple clients can establish a shared secret with AC to authenticate directly with AC.

The extensibility of Access Control allows for easy integration of authentication and authorization through many identity providers without the need for refactoring code. As Access Control evolves, support for authentication against Facebook Connect, Google Accounts, and Windows Live ID can be quickly added to an application. To reiterate: over time, it will be easy to authorize access to more and more users without having to change the code base.

When using AC, the user must obtain a security token from AC in order to log in; this token is similar to a signed email message from AC to your service with a set of claims about the user’s identity. AC doesn’t issue a token unless the user first provides his or her identity by either authenticating with AC directly or by presenting a security token from another trusted issuer (such as ADFS) that has authenticated that user. So by the time the user presents a token to the service, assuming it is validated, it is safe to trust the claims in the token and begin processing the user’s request.

Single sign-on is easier to achieve under this model, so a customer’s service is no longer responsible for:

Under this model, a customer’s service can make identity-related decisions based on claims about the user made by a trusted issuer like AC. This could be anything from simple service personalization with the user’s first name, to authorizing the user to access higher-valued features and resources in the customer’s service.

Standards

Due to the fact that single sign-on and claims-based identity have been evolving since 2000, there are a myriad of ways of doing it. There are competing standards for token formats as well as competing standards for the protocols used to request those tokens and send them to services. This fact is what makes AC so useful, because over time, as it evolves to support a broader range of these standards, your service will benefit from broader access to clients without having to know the details of these standards, much less worry about trying to implement them correctly.

Security Assertion Markup Language (SAML) was the first standard. SAML specified an XML format for tokens (SAML tokens) in addition to protocols for performing Web App/Service single sign-on (SAML tokens are sometimes referred to inside Microsoft as SAMLP–for the SAML protocol suite). WS-Federation and related WS-* specifications also define a set of protocols for Web App/Service single sign-on, but they do not restrict the token format to SAML, although it is practically the most common format used today.

To Summarize

The Service Bus and Access Control constituents of the Windows Azure platform provide key building block services that are vital for building cloud-based or cloud-aware applications. Service Bus enables customer to connect existing on-premises applications with new investments being built for the cloud. Those cloud assets will be able to easily communicate with on-premises services through the network traversal capabilities, which are provided through Service Bus relay.

Overall, the Windows Azure platform represents a comprehensive Microsoft strategy designed to make it easy for Microsoft developers to realize the opportunities inherent to cloud computing. The Service Bus and Access Control offer a key component of the platform strategy, designed specifically to aid .NET developers in making the transition to the cloud. These services provide cloud-centric building blocks and infrastructure in the areas of secure application connectivity and federated access control.

For more information on the Service Bus & Access Control, please contact a Nubifer representative or visit these Microsoft sponsored links: