Monthly Archives: August 2010

Azure Development Fabric with HTTPS

127.0.0.1

It always helps to have tips for common problems. Lately I’ve been looking for helpful hints related to Azure. Usually there is something to be found with the help of Google. Sometimes it is spread around a few different places for one topic.

The hints for this blog post is using HTTPS with Azure Development Fabric. Here are the things I wish someone had told me.

  1. You can select HTTPS on the Web Role properties for an endpoint. You cannot select a hostname to go with this.
  2. All connections are based on using 127.0.0.1 for the server web address.
  3. If IIS is installed (or some other web server), the Windows Azure Web Server will pick the next highest port (either HTTP 81 or HTTPS 444).
  4. The development web server for Azure is not connected to IIS and this can cause confusion sometimes.
  5. Starting the code from Visual Studio will start up to two instances of web browser based on HTTP and HTTPS.  You can control which start from the properties for the web role.
  6. The Azure SDK automatically creates a certificate for 127.0.0.1 when it is first run in Dev Fabric.  This certificate is the same for everyone and it appears to be impossible to switch to a different certificate for Dev Fabric.
  7. Do not ever delete the 127.0.0.1 certificate using the certificate management tools unless you want to re-install the Azure SDK.
  8. You can get the 127.0.0.1 certificate to be trusted by copying the certificated to trusted root (very important for your sanity).
  9. Typically the address for HTTPS is https://127.0.0.1:444/ for your web role.
  10. It is possible to use HTTPS with 127.0.0.1 and have it work with Windows Identity Framework and ADFS.
  11. The settings in the configuration for certificates and the SSL certificate only apply to Azure and not Dev Fabric

If you are only interested in providing HTTPS on Azure, there is a really good post here.

Initially I was only focusing on running the web role without the Dev Fabric.  This gives more flexibility with the configuration (server name and real IIS) but it simply does not work with the Dev Fabric.

After a bit of churn, the code now conforms to using 127.0.0.1 and luckily this should make it easier to share code with team workers.

The philosophy, perhaps, was to make the code not care about the host in any way so that it would easily be published to Azure.

HTTPS is key to supporting Federated Identity.  Without it, there is not much hope for passive federation.

ADFS 2.0 Master Page

Active Directory Federation Server (ADFS) runs on IIS web server. At first it appeared to be a bit mysterious how this was laid out but it is now obvious that it follows the rules of a typical Microsoft ASP.NET web site.

Inside the web files for ADFS lives the Master Page. For those not familiar with ASP.NET, the Master Page acts as a template for all pages based on it. It allows for a more consistent look and makes it easier to create new content. One change on the master page propagates immediately to all children pages.

This means that it might be possible to customize the look of ADFS without too much effort. Here is sampling of the ADFS Master Page. Click on the image to get a PDF listing.

The interesting bit about the master page is its support for logo files.  In the code above, it detects a configuration setting for ‘logo’ and potentially uses this as part of the ADFS pages.  This code is slightly tricky since it using old ASP tricks.  If I understand this correctly, it is conditionally injecting the logo image based on the configuration not having a null or empty string.

In practical use, you just need a setting in web.config to get this going.

appSettings comes directly under the configuration section.  Uncomment the ‘add key=”logo”‘ line and change the value to the URL of your desired header logo.

Not sure about this but you might need to restart the web server to make it take effect.

It is impressive that ADFS left the web pages and code in the open.  Potentially this could lead to all kinds of customization.

Microsoft has documented that this is possible.

One line XML files

XML can be hard to read without any formatting. The computer could care less but human eyes cannot easily see the patterns.

This recently became obvious with the FedUtil program that comes with Windows Identity Foundation. All the XML ends up on a single line.

There are two easy ways to solve this problem:

1. Use Visual Studio and press CTRL-K CTRL-D to automatically format
2. Open the file in Internet Explorer (make sure the file ends with XML)

It makes a huge difference. Human readable, imagine that.

Update:

It is possible to apply this strategy to source as well in Visual Studio:

  1. Select the text you want to auto format (Ctrl-A for everything in the document)
  2. Ctrl-K, Ctrl-F (or Edit/Advanced/Format Section)

This can be very handy for normalizing the code without spending time making sure everything aligns properly.