Windows Azure Security Best Practices – Part 6: How Azure Services Extends Your App Security

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:

• With Windows Azure Active Directory you create single sign on application with the authentication brokered in an application residing in the cloud. Using Access Control Service feature, you can map identities from various providers to the claims that your application understands.
• Windows Azure Connect uses industry-standard end-to-end IPSEC protocol to establish secure connections between on-premise machines and roles in the cloud. This allows you to connect to your cloud app as if it were inside the firewall.
• With Service Bus you can use secure messaging and relay capabilities to enable your distributed and loosely-coupled applications.

Windows Azure Active Directory

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 Services

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:

• Integration with Windows Identity Foundation (WIF)
• Out-of-the-box support for popular web identity providers including Windows Live ID, Google, Yahoo, and Facebook
• Out-of-the-box support for Active Directory Federation Services (AD FS) 2.0
• Support for OAuth 2.0 (draft 10), WS-Trust, and WS-Federation protocols
• Support for the SAML 1.1, SAML 2.0, and Simple Web Token (SWT) token formats
• Integrated and customizable Home Realm Discovery that allows users to choose their identity provider
• An Open Data Protocol (OData)-based management service that provides programmatic access to the ACS configuration
• A browser-based management portal that allows administrative access to the ACS configuration

ACS is compatible with virtually any modern web platform, including .NET, PHP, Python, Java, and Ruby.

Getting Started with Access Control Service

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

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:

• Distributed applications. For cloud applications hosted in a hybrid environment, Windows Azure Connect maintains secure connections with on-premise infrastructure without the creation of custom codes. For example, a web application hosted in Windows Azure can securely access an on-premise SQL Server database server or authenticate users against an on-premise Active Directory service.
• Remote debugging. With Windows Azure Connect, you can create a direct connection between your local development machine and applications hosted in Windows Azure, which allows you to troubleshoot and debug them using the same tools you would use for on-premise applications.

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.

Getting Started with Windows Azure Connect

See Getting Started with Windows Azure Connect.

Service Bus

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:

• Asynchronous Cloud Eventing – Distribute event notifications to occasionally connected clients (for example, phones, remote workers, kiosks, and so on)
• Event-driven Service Oriented Architecture (SOA) – Building loosely coupled systems that can easily evolve over time
• Advanced Intra-App Messaging – Load leveling and load balancing for building highly scalable and resilient applications

Service Bus Relayed Messaging

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

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.

Getting Started with Service Bus

See:

• An Introduction to the Service Bus (video)
• Getting Started with the Service Bus
• Developing Applications that Use the Service Bus
• Service Bus topic on MSDN

Next Up

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:

• Windows Azure Security Best Practices -- Part 1: The Challenges, Defense in Depth.
• Windows Azure Security Best Practices -- Part 2: What Azure Provides Out-of-the-Box.
• Windows Azure Security Best Practices – Part 3: Identifying Your Security Frame.
• Windows Azure Security Best Practices – Part 4: What Else You Need to Do.
• Windows Azure Security Best Practices – Part 5: Claims-Based Identity, Single Sign On.
• Windows Azure Security Best Practices – Part 7: Tips, Tools, Coding Best Practices.

 

Bruce D. KyleISV Architect Evangelist | Microsoft Corporation