How Windows Azure Services extends Application security

A variety of Windows Azure services can help you extend application security to the cloud.

There are three services that provide identity mapping between multiple providers, connections between internally deployed data centers, and application features that send messages to each other, regardless of where the application is located.

using Windows Azure Active Directory, you can create a single sign-on application on your application through proxy authentication for applications located in the cloud. With the access Control Services feature, you can map identities from multiple providers to claims that the application can identify. With Service bus, you can use secure messaging and relaying to enable loosely coupled distributed applications.

Windows Azure Active Directory

Windows Azure Active Directory is a cloud service that provides identity authentication and access capabilities for applications on Windows Azure and Microsoft Office 365. Windows Azure Active Directory is a multi-tenant cloud service, and Microsoft Office 365 relies on its authentication infrastructure.

Windows Azure Active directory makes it easy to migrate your applications to the cloud with features that are recognized as enterprise-quality Active Directory. You can use Access control services (ACS), a feature of Windows Azure Active directory, to enable single sign-on, security-enhanced applications, and simple interoperability with existing Active directory deployments.

Access Control Services

The Access Control Service (ACS) allows you to integrate point logon (SSO) and centralized authorization into a WEB application. It works for most modern platforms and integrates with WEB and enterprise identity providers.

ACS is a cloud-based service that provides a simple way to authenticate and authorize users to gain access to WEB applications and services, and to isolate authentication and authorization from code. You can have ACS schedule the user's authentication and most authorization without having to implement the authentication system with the application-specific user account. ACS can integrate standards-based identity providers, including enterprise directories, such as Active directory, and Web identity providers such as Windows Live IDs, Google, Yahoo!, and Facebook.

The Access Control service is a key part of developing a single sign-on strategy for applications that use claim.

With ACS, authorization decisions can be drawn from the application into a set of declarative rules to convert incoming security claim into claim that the application and the service can identify. Define these rules by using a simple, familiar programming model to make their code clearer.

ACS can also be used to manage client permissions, thus saving energy and reducing the complexity of developing these features.

In the scenario shown in the previous illustration, the end user accesses the application using a browser. Browsers accept credentials for multiple identity providers-users can use the Windows Live ID, Google, Yahoo!, Facebook, or the customer's Active Directory to log on to the application. After obtaining token from an identity provider, ACS converts token using the rules you provide. For example, an identity provider can deliver e-mail to ACS, and you can change the e-mail message in token to a claim named "Electronicmail" (if required).

Applications rely on ACS to provide claim in an application-identifiable way.

The following illustration shows the steps between parts of a WEB application. WEB service applications are similar.

Your application will be displayed as the relying party.

ACS is compatible with most common programming and run-time environments and supports multiple protocols, including Open Authorization (OAuth), OpenID, Ws-federation, and WS.

ACS provides the following features:

Integrates with Windows Identity Foundation (WIF) with support for common Web identity providers (including Windows Live IDs, Google, Yahoo, and Facebook) for Active Directory Federation Services (AD FS) 2.0 self-supporting Support OAuth 2.0, WS, and Ws-federation protocols support SAML 1.1, SAML 2.0, and simple Web Token (SWT) These token formats allow users to choose their identity provider's customizable integrated home Realm Discovery based on the Open Data Kyoto (OData) management Service, which provides programmatic access to ACS configuration Configure a browser-based management portal for administrative access

ACS can be compatible with almost all modern Web platforms, including. NET, PHP, Python, Java, and Ruby.

Getting Started with access control services

ACS Quick Track-Getting Started guide.

Access Control Services 2.0 samples and documents were once available through the CodePlex project containing the ACS 2.0 production version and the documentation, and can now be accessed directly via MSDN.

Service Bus

Service Bus provides secure messaging and relaying capabilities to build loosely coupled distributed applications in the cloud. These messaging scenarios can be used to protect applications that are connected to a client in the cloud to run in an internal deployment, or to support endpoints on Windows Azure.

Relay and brokered message delivery. The Relay service provides many different relay connection options, and can even help negotiate direct connections if possible. Relay services support Traditional one-way messaging, request/response messaging, and peer-to-peer messaging. It also supports the entire Internet-wide event distribution and provides a publish/subscribe scenario and bidirectional socket communication to improve point to point efficiency. Unlike relay messaging scenarios, brokered messaging can be considered asynchronous or "temporarily detached." Producers (senders) and consumers (receivers) do not need to be online at the same time.

The new features introduced in September 2011 support queues, themes, subscriptions, and so on, improving the delivery/subscription messaging, thereby enhancing Service bus. This release also supports the following new scenarios on the Windows Azure platform:

Asynchronous Cloud events-distributing event notifications to accidentally connected clients (for example, event-driven service-oriented architecture (SOA) for telephony, remote worker, kiosk, etc.-building a loosely coupled system that can evolve over time--load level adjustment and load balancing Used to build highly scalable and resilient applications.

Service Bus Relay Message Delivery

Let's say you run your application within the internal deployment Customer data Center (or in a private cloud). You can expose the application to the user without exposing it to the cloud. The centralized "relay" service running in the cloud supports many different transport protocols and WEB service standards, including
SOAP, WS, and REST.

With service Bus relay messaging, you can create a basic Windows communication Foundation (WCF) service application and a WCF client application. The former is configured to register the publishing endpoint with the service bus, which is invoked through the service bus endpoint. Both host and client applications execute on Windows Server or desktop computers (that is, they are not hosted on Windows Azure) and Access Service bus using common standard protocols and security measures.

For a tutorial on how to build an application that uses service bus relay messaging, see service Bus relay messaging tutorial.

Service bus brokered message delivery

Service bus brokered messaging can be viewed as asynchronous or decoupled messaging, providing support for publish-subscribe, temporary separation, and load-balancing scenarios through the Service bus messaging infrastructure. Decoupled communications have many advantages, such as connecting clients and servers as needed and performing operations asynchronously.