Connecting Cloud Services with Virtual Machines in Windows Azure

As of Windows Azure SDK 1.7, Microsoft has enabled us to connect a cloud service with a virtual machine in Windows Azure. Now that the general availability of Windows Azure Infrastructure Services has been announced, Microsoft also supports it.

The common scenario for this is connecting from a public ASP.NET web application that is running in a cloud service to a private SQL Server database that is running in a virtual machine via a virtual network. This post walks you through how to deploy this scenario.

Create the virtual network

The first step is to create a virtual network.

For information about how to create this virtual network, see the Create a Virtual Network in Windows Azure tutorial.

This tutorial creates a cloud-only virtual network, but you can also create a point-to-site virtual network (see the Configure a Point-to-Site VPN in the Management Portal article) or a site-to-site virtual network (see the Create a Virtual Network for Site-to-Site Cross-Premises Connectivity tutorial) if you must  connect with an on-premises resource such as Active Directory, a DNS server, or similar.

The tutorial creates the YourVirtualNetwork virtual network that has an address space with the following two subnets:

  1. FrontEndSubnet, which will host the web role running the public ASP.NET web application
  2. BackEndSubnet, which will host the virtual machine running the private SQL Server database

Create the virtual machine

The next step is to create a virtual machine that is to host the private SQL Server database.

For information about how to create this virtual machine, see the Provisioning a SQL Server Virtual Machine on Windows Azure tutorial.

This tutorial creates a virtual machine using a pre-built SQL Server virtual machine image from the Windows Azure virtual machine gallery, but you can also create one using a “pre-owned” virtual machine image from an on-premises virtual machine template.

A few notes about the tutorial:

    • When creating the virtual machine, on the Virtual machine mode page, in the REGION/AFFINITY GROUP/VIRTUAL NETWORK box, select the YourVirtualNetwork virtual network that was created in the previous step and in the VIRTUAL NETWORK SUBNETS box, select the BackEndSubnet subnet that was also created in the previous step.
    • After the virtual machine is provisioned, you don’t have to create a TCP endpoint for the virtual machine unless you must connect to it from the public network (which isn’t required for this walkthrough since we are connecting from a web role to the virtual machine via a private network).
    • If the virtual network that was created in the previous step wasn’t provisioned with either a public DNS server or an on-premises one, determine the IP address of the virtual machine by running the ipconfig.exe command-line tool.
    • After the database engine has been setup, you can deploy the SQL Server database to it.

Deploy the cloud service

The last step is to deploy a cloud service that is to host the public ASP.NET web application.

To connect from the cloud service to the virtual machine via the virtual network , the NetworkConfiguration element must be added to the service configuration file for the cloud service.

The NetworkConfiguration element, which describes the network configuration into which the cloud service is to be deployed, includes the following sub-elements:

  • Dns element: Specifies the DNS server(s) to be used by the cloud service.
  • VirtualNetworkSite element: Determines the virtual network to which the cloud service is to be deployed.
  • AddressAssignments element: Configures mappings from roles for the cloud service to subnets for the virtual network.

To connect the cloud service with the virtual machine in Windows Azure, you must modify both the service configuration for the cloud service and the connection string for the ASP.NET web application.

Service configuration

To connect from the cloud service to the virtual machine via the virtual network, you must add the VirtualNetworkSite and AddressAssignments elements to the service configuration for the cloud service as follows:

<?xml version="1.0" encoding="utf-8"?>
  <ServiceConfiguration ...>
    <Role name="WebRole1">
    ...
    </Role>
    <NetworkConfiguration>
       <VirtualNetworkSite name="YourVirtualNetwork" />
       <AddressAssignments>
          <InstanceAddress roleName="WebRole1">
            <Subnets>
             <Subnet name="FrontEndSubnet" />
            </Subnets>
          </InstanceAddress>
       </AddressAssignments>
    </NetworkConfiguration>
</ServiceConfiguration>

This service configuration deploys the cloud service to the YourVirtualNetwork virtual network and maps the web role to the FrondEndSubnet subnet.

You can only deploy a cloud service to a single virtual network, but you can map a role to multiple subnets, which allows the role to be assigned an IP address from the next subnet if the previous one doesn’t have any more IP addresses when a new instance for the role is created.

If the virtual network that was created in the first step was provisioned with a DNS server, you must also add the Dns element to to the service configuration as follows:

<?xml version="1.0" encoding="utf-8"?>
<ServiceConfiguration ...>
   <Role name="WebRole1">
   ...
   </Role>
   <NetworkConfiguration>
     <Dns>
       <DnsServers>
         <DnsServer name="YourDns" IPAddress="10.4.3.1" />
       </DnsServers>
     </Dns>
     <VirtualNetworkSite name="YourVirtualNetwork" />
     <AddressAssignments>
       <InstanceAddress roleName="WebRole1">
         <Subnets>
           <Subnet name="FrontEndSubnet" />
         </Subnets>
       </InstanceAddress>
     </AddressAssignments>
   </NetworkConfiguration>
</ServiceConfiguration>

Connection string

To connect from the public ASP.NET web application to the private SQL Server database, modify the connection string for the ASP.NET web application as follows:

connectionString="Server{DnsNameOrIPAddressOfVirtualMachine};Integrated Security=false;User ID={LoginUserName};Password={LoginPassword};" providerName="System.Data.SqlClient"

Run the ASP.NET web application and it should connect with the SQL Server database!

Configuring ASP.NET 4.5 for Windows Azure Active Directory

Yesterday, the Active Directory team announced the Developer Preview of Windows Azure Active Directory (AD). Windows Azure AD is Identity Management as a Service. Today, it is the identity provider for Office 365, Dynamics CRM Online, and Windows Intune. The Developer Preview enables developers to implement Web Single Sign-On (SSO) for Software as a Service, and line-of-business, and cloud applications.

With the new announcement, Vittorio Bertocci published a deep-dive article that describes Web SSO with Windows Azure AD. A how-to guide, which walks developers through implementing Web SSO with ASP.NET, was also published to the Windows Azure website.

However, the how-to guide only discusses implementing Web SSO with ASP.NET 4. This post walks you through what is required to implement it with ASP.NET 4.5.

Implementing Web SSO with ASP.NET 4.5

With Visual Studio 2012 and .NET Framework 4.5, building claims-aware applications has changed.

Firstly, the Visual Studio tools (such as Add STS Reference…) and the command-line tool, FedUtil.exe, that have been packaged in the Windows Identity Foundation (WIF) SDK are no longer be shipped. Instead, you install a new Visual Studio extension, Identity and Access Tool. Secondly, the claims-related classes that have also been packaged in the WIF SDK are a first-class citizen of the core framework. In fact, many of these classes (such as the Claim class) are packaged in the mscorlib assembly!

All of this means that how you configure an ASP.NET Web Forms or MVC application for federation with a remote Security Token Service (STS)—in the context of this post, this STS is Windows Azure AD—is different.

If you are walking yourself through the how-to-guide that I described earlier, you must configure Fabrikam’s ASP.NET MVC application for federation with Windows Azure AD (see Step 3 – Protect the ASP.NET application via WS-Federation and onboard the first customer in this guide) as follows:

1. In Visual Studio, right-click the ASP.NET MVC Web Application project in Solution Explorer and select Identity and Access….

2. In the Providers tab of the Identity and Access window:

3. Click OK.

The following figure shows the completed Identity and Access window.

Identity and Access window

4. In the ASP.NET MVC Web Application project, open the Web.config file.

5. In the Web.config file, add the certificateValidation element to the system.identityModel/identityConfiguration element as follows:

<certificateValidation certificateValidationMode="None" />

The following snippet shows the completed Web.config file.

<system.identityModel>
<identityConfiguration>
<audienceUris>
<add value="spn:7829c758-2bef-43df-a685-717089474505@e4073280-196b-408f-9d40-0be89978fda0" />
</audienceUris>
<issuerNameRegistry type="System.IdentityModel.Tokens.ConfigurationBasedIssuerNameRegistry, System.IdentityModel, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089">
<trustedIssuers>
<add thumbprint="3464C5BDD2BE7F2B6112E2F08E9C0024E33D9FE0" name="spn:00000001-0000-0000-c000-000000000000@495c4a5e-38b7-49b9-a90f-4c0050b2d7f7" />
</trustedIssuers>
</issuerNameRegistry>
</identityConfiguration>
</system.identityModel>
<system.identityModel.services>
<federationConfiguration>
<cookieHandler requireSsl="false" />
<wsFederation passiveRedirectEnabled="true" issuer="https://accounts.accesscontrol.windows.net/v2/wsfederation" realm="spn:7829c758-2bef-43df-a685-717089474505@e4073280-196b-408f-9d40-0be89978fda0" reply="https://localhost/OrgIdFederationSample" requireHttps="false" />
</federationConfiguration>
</system.identityModel.services>

6. Complete steps 7—12 of Step 3 – Protect the ASP.NET application via WS-Federation and onboard the first customer in the guide.

When you run the ASP.NET MVC Web application project, you will be redirected to the Office 365 identity provider page, where you can log yourself in using your Office 365 credential!