Are you a startup?
Get BizSpark cloud access
Get up to $3,700 of cloud benefits
Don’t have MSDN?
Here’s cloud access
Several Windows Azure services help you extend your application security into the cloud.
Three services can help you in providing identity mapping between various providers, connections between an on premises data center, and abilities for applications (where ever they reside) to send messages to each other:
Windows Azure Active Directory is a cloud service that provides identity and access capabilities for applications on Windows Azure and Microsoft Office 365. Windows Azure Active Directory is the multi-tenant cloud service on which Microsoft Office 365 relies on for its identity infrastructure.
Windows Azure Active Directory utilizes the enterprise-grade quality and proven capabilities of Active Directory, so you can bring your applications to the cloud easily. You can enable single sign-on, security enhanced applications, and simple interoperability with existing Active Directory deployments using Access Control Service (ACS), a feature of Windows Azure Active Directory.
Access Control Service (ACS) allows you to integrate single sign on (SSO) and centralized authorization into your web applications. It works with most modern platforms, and integrates with both web and enterprise identity providers.
ACS is a cloud-based service that provides an easy way of authenticating and authorizing users to gain access to your web applications and services while allowing the features of authentication and authorization to be factored out of your code. Instead of implementing an authentication system with user accounts that are specific to your application, you can let ACS orchestrate the authentication and much of the authorization of your users. ACS integrates with standards-based identity providers, including enterprise directories such as Active Directory, and web identities such as Windows Live ID, Google, Yahoo!, and Facebook.
Access Control Service is a key part of building out a single sign on strategy for applications that use claims.
ACS enables authorization decisions to be pulled out of the application and into a set of declarative rules that can transform incoming security claims into claims that applications and services understand. These rules are defined by using a simple and familiar programming model, resulting in cleaner code.
ACS can also be used to manage client permissions, thus saving the effort and complexity of developing these capabilities.
In the scenario shown in the diagram above, an end user is using a browser to access the application. The browser accepts credentials from various identity providers – your user can log into your application using Windows Live ID, Google, Yahoo!, Facebook, or your customer’s Active Directory. Once it gets the token from the identity provider, ACS transforms the token using rules you provide. For example, the identity provider can pass through the email and you can change the email in the token to a claim named “electronicmail” if you so desired.
The application trusts ACS to provide the claims in a manner that the application understand.
The following diagram show the steps between each of the parts of a Web application. A Web Services application is similar.
Your application is shown as the relying party.
ACS is compatible with most popular programming and runtime environments, and supports many protocols including Open Authorization (OAuth), OpenID, WS-Federation, and WS-Trust.
The following features are available in ACS:
ACS is compatible with virtually any modern web platform, including .NET, PHP, Python, Java, and Ruby.
ACS Fast Track – A Guide For Getting Started.
Access Control Service 2.0 Samples and Documentation is available through a CodePlex project contains code samples and documentation for the production release of ACS 2.0.
Windows Azure Connect provides an easy way to set up network-level connectivity between Windows Azure services and on-premise resources such as database servers and domain controllers, allowing each access to the other as if they were on the same network.
Here are two scenarios where Windows Azure Connect help you extend your application into the cloud:
Windows Azure Connect uses industry-standard end-to-end IPSEC protocol to establish secure connections between on-premise machines and roles in the cloud. Unlike a traditional Virtual Private Network (VPN), which establishes secure connectivity at gateway level, Windows Azure Connect offers more granular control by establishing secure connections at a machine and role level.
See Getting Started with Windows Azure Connect.
Service Bus provides secure messaging and relay capabilities that enable building distributed and loosely-coupled applications in the cloud. These messaging scenarios can be used to secure applications that are running on premises to clients in the cloud. Or they can support endpoints on Windows Azure.
Relayed and Brokered Messaging. The relay service provides a variety of different relay connectivity options and can even help negotiate direct peer-to-peer connections when it is possible. The relay service supports traditional one-way messaging, request/response messaging, and peer-to-peer messaging. It also supports event distribution at Internet-scope to enable publish/subscribe scenarios and bi-directional socket communication for increased point-to-point efficiency. In contrast to the relayed messaging scheme, brokered messaging can be thought of as asynchronous, or “temporally decoupled.” Producers (senders) and consumers (receivers) do not have to be online at the same time.
New features introduced in September 2011 enhances Service Bus with improved pub/sub messaging by supporting features such as Queues, Topics, Subscriptions. This release also enables new scenarios on the Windows Azure platform, such as:
Suppose you had an application running in a customer data center on premises (or within a private cloud.) You could expose the application to your users in a way that does not expose the application to the cloud. A centralized “relay” service running in the cloud supports a variety of different transport protocols and Web services standards, including SOAP, WS-*, and REST.
Using Service Bus Relayed Messaging you can create a basic Windows Communication Foundation (WCF) service application that is configured to register an endpoint for publication with the Service Bus and a WCF client application that invokes it through the Service Bus endpoint. Both the host and client applications are executed on a Windows server or desktop computer (that is, they are not hosted in Windows Azure) and use a common standard protocol and security measures to access the Service Bus.
For a tutorial that describes how to build an application that uses the Service Bus “relayed” messaging capabilities, see Service Bus Relayed Messaging Tutorial.
Service Bus Brokered Messaging capabilities can be thought of as asynchronous, or decoupled messaging features that support publish-subscribe, temporal decoupling, and load balancing scenarios using the Service Bus messaging infrastructure. Decoupled communication has many advantages; for example, clients and servers can connect as needed and perform their operations in an asynchronous fashion.
For tutorials on how to implement brokered messaging in .NET or using REST, see Service Bus Brokered Messaging Tutorials.
Windows Azure Security Best Practices – Part 7: Tips, Coding Best Practices. I kept running into more best practices. So here are a few more items you should consider in securing your Windows Azure application.
Here are links to the articles in this series:
Bruce D. Kyle ISV Architect Evangelist | Microsoft Corporation