Hosting a Web Site as an Azure Cloud Service

I’ve used the Shibboleth Service Provider (SP) for authentication of web applications running on my own IIS web servers. I wrote a simple ASP.Net web site in Visual Studio and configured it to run in IIS and then added the Shibboleth SP to it. This is a fairly straightforward task with much of the work done for you by the Shibboleth SP installer. The only thing that remained to be done after the SP installation was updating some configuration files and registering my SP with my university’s IdP. Having completed this project I wondered if this process could be repeated using Azure as the web hoster.

Shibboleth Service Provider

The Shibboleth SP comes in two flavors: IIS and Apache. As I outlined in my prior post, there are several different options for web hosting in Azure. I could create a virtual machine running either Windows or Linux and install the Apache web server on it. I’m not going down that road for a variety of reasons that I’ve already noted. The simple web site option won’t work because it doesn’t support SSL or startup scripts. That leaves the option of exploring the Cloud Service and its IIS web role to do this Shibboleth SP hosting.

The IIS version of the Shibboleth SP is composed of two parts, an ISAPI filter DLL that intercepts requests before they reach your web application code and a Windows service that maintains SP state. The SP is packaged as an MSI and is installed by the Windows installer. This means that there must be a way to run the MSI on your Azure web host before the web application starts. Fortunately the Cloud Service web role can be configured to run startup scripts. There is another wrinkle to consider. The Shibboleth SP MSI uses the IIS 6.0 compatibility API to install its ISAPI filter. I did a bit of experimenting and discovered that the Azure Windows Server 2012 web role does not have the IIS 6.0 compatibility API installed. Thus additional startup steps are required.

Steps to Create an Azure Cloud Service Web App

The analog to creating a local IIS web app is to create an Azure cloud service web role. To create an Azure web site you need to have an Azure subscription. There are several ways to obtain said subscription. One option is to sign up for a 90-day free trial. If you do this you must cancel within those initial 90 days or charges will begin to accrue. If you have an MSDN subscription, that entitles you to a $100/month subsidy for Azure services. This is a good way to kick the tires and even to run a small web site. Azure only supports two different kind of user login accounts: Live accounts or Office 365 accounts. Since MSDN also requires the use of a Live account, this is a straightforward way to get an Azure subscription.

With a subscription in hand, you can log into the Azure Management Portal using the corresponding Live or Office 365 account. The next step is to create a new web application. The Azure documentation on creating a cloud service is here.

This blog post assumes you are using Visual Studio. The steps I describe apply to both VS 2010 and VS 2012 although the later version has more built-in support.

  1. Install the Windows Azure SDK. The version that is current as of the writing of this post is 2.0. This installs VS templates and extends the VS menus with Azure-specific commands. It also installs Azure libraries and tools.
  2. Open VS and create a new project using the Visual C# Cloud template.
    1. Go with the default .Net framework version. With VS 2010 that is 4.0. With VS 2012, that is 4.5. The .Net version support is one of the biggest differences between VS versions.
    2. You will need to name the project. Use whatever name makes sense to you; this name will not be used by Azure.
    3. Leave the “Create directory for solution” checkbox checked.
    4. After you click OK the “New Windows Cloud Service” dialog will open. It lists 3 ASP.Net web role templates along with others. Choose whichever template you may be familiar with using. If you are not familiar with ASP.Net, then beware; all of these are complex web application templates. I chose the ASP.Net Web Role and discovered that it created several hundred web site files. Yikes! VS does have an “Empty ASP.Net web site” template, but it is not available as one of the cloud service roles. At any rate, you can accept the proposed name of WebRole1 or you can click on the name and an edit icon (a pencil) appears. If you click on the pencil you can rename the web role to something more meaningful to your web application. When you click OK VS whirs away for a while and then presents to you the beginnings of a web application.
    5. Create whatever basic web site functionality you may want. Build it and run it to ensure it works.
  3. Sign up for an Azure account and log in to the Azure Management Portal
  4. Create a Cloud Service application. You can use the quick create option.
    1. You will need to choose a URL. Whatever you choose will be prepended to .cloudapp.net. It is possible to use your own full DNS name, but I won’t go into that here. Rather, you need to choose a name that is unique within the cloudapp.net namespace. For example, if you choose myshibbolethsp, then your web site’s URL will be https://myshibbolethsp.cloudapp.net.
    2. You should select a region that is close to your location to keep latency and transfer time to a minimum.
    3. If you have more than one Azure subscription, you will be asked which to use for this new cloud service.
    4. When you are done you will have an empty cloud service with no running instances.
  5. Now upload your web application to Azure. Go to the Visual Studio Solution Explorer. There will be a cloud service project in addition to the web role project. Right-click on the cloud service project and choose Publish…
    1. This opens the Publish Windows Azure Application wizard. Follow the steps in this MSDN Article to complete the upload.
    2. Choose the option to enable remote desktop. The Azure tools automatically create a remote-session encryption certificate and does the VS and Azure configuration for remote desktop.
    3. It will ask you for a storage account for debugging. You can create one if you don’t already have one. It won’t actually be used unless you add Azure debug logging to your code.
    4. Since this is a test cloud service you can select deploy to production. Staging would have a different URL which will complicate things unnecessarily.
    5. It takes a while to upload the project packages and then start the web role. You can monitor the progress in the VS output pane.
  6. You can try to access the web site after VS says it has successfully deployed. You can also go to the Azure Developer’s Portal to monitor and/or configure your new cloud service application.

Now that you have a running Azure cloud service application, you can configure it for SAML authentication using the Shibboleth SP. I will demonstrate how to do that in my next post.

Hosting Options for a Web Application

In my prior post I discussed SAML as a popular federated authentication protocol standard. To create a SAML-protected web site, in fact, to create any web site, you need to have a web server. You can use almost any type of computer as a web server, but for reasons of reliability and load handling, you’d probably want a server-class machine. Server-class computers are much more expensive than commodity workstation machines. You would probably also be concerned about the ancillary systems such as the networking gear and power conditioning components. For these and may other reasons you may wonder if it would be advantageous to have someone else provide a web server that you could use. This type of service is commonly termed web hosting.

Editorial Note: I dislike using the term “cloud” to describe what is nothing more than hosted services. That is, services that are running in someone else’s data center. Technical people love latching on to buzzwords. These are terms that get used way beyond their technical origins and often to the point where they become meaningless. Despite my objections, it is difficult to discuss Microsoft hosting services without using the word “cloud.”

So, I’d like to create a web site whose content is protected by SAML authentication. What are my options? First off, I’ll use the Shibboleth open-source service provider as the SAML software for the web site. Then I’d like to have someone else host it so I don’t have to invest in server-class infrastructure. What are my hosting choices?

Software as a Service

Software as a Service, abbreviated SAAS, is very common and most people have used it. Imagine a software application that runs on your computer such as Microsoft Word/Office or Intuit’s Turbo-Tax. Office 365 and Turbo-Tax Online are SAAS versions of those programs. Other common examples of SAAS include Hotmail, G-Mail and Google Docs.

Infrastructure as a Service

There are a number of hosting providers that allow you to upload a virtual machine. They will run it for you on a virtual server and will provide the networking and related components. This is IAAS. You build your own web server, either physically or within your own virtualization environment. You then author a web application using a framework supported by your web server and configure this web server as needed to run the application. Finally you upload the virtual server image of your web server to the IAAS provider. Thus you provide and configure the operating system, the web server service, and any libraries or other programs needed by your web application. You also have to provide the health and load monitoring of your web application. You do all of the work to create a web server and someone else supplies the infrastructure to run that web server. IAAS can host nearly any type of server that communicates over a network.

Platform as a Service

PAAS falls in between SAAS and IAAS. The PAAS vendor provides a virtual environment that includes an operating system and a web server service and related support services such as monitoring. There are no clean lines, it is a continuum such that it is difficult to say precisely where PAAS stops and SAAS begins. I like to think that if it requires writing computer code, then it is PAAS. Thus services like BlogSpot and WordPress seem to be more SAAS than PAAS.

Microsoft Windows Azure

A number of companies offer variations on these hosting services. As I mentioned earlier, Microsoft Office 365 is an example of SAAS. I used to work on Microsoft’s Azure, so I will discuss some of its hosting services. Azure provides both PAAS and IAAS options. Azure can host your virtual machines; that is their IAAS offering. Azure has two PAAS variations that they term Web Sites and Cloud Services. The web site service is new and is currently limited to vanilla ASP.Net web sites that cannot employ SSL/TLS. The cloud service variation is much more powerful and configurable. More about that in a moment. Azure also offers a number of supporting services which includes SQL databases, high availability no-SQL storage, networking services such as VPN and event messaging, and directory services and this list is growing on a nearly monthly basis.

Azure Cloud Services

An Azure cloud service allows you to create instances of two different roles; a web server role and a worker role. The idea is that a sophisticated web application will need front end services to process web requests (the web role) and back end services to do extended processing (the worker role). The typical scenario would have a web role field a request for some “thing” that is part of the web application. The web role would then queue up a request to the worker role to get that “thing.” The queued request would include the address to which the response should be directed. The worker role would do whatever processing is needed (say, do a cart check-out) and then post an item to the response queue with the results. A web role instance would read the response queue in between handling requests so that the results can be sent back to the requesting web browser.

Communications Infrastructure

Azure provides a number of mechanisms that web roles and worker roles can employ for communications.

  • Azure storage provides highly-available and fault-tolerant storage. There are 3 copies of all datum stored in a data center and, if needed, the data can be replicated between Azure data centers.
    • Blob storage – allows the storage of very large datums, each with a unique address. You could build a photo-sharing site using blob storage for the photos.
    • Table storage – on-the-fly table creation using standard .Net datatypes for each table column. One element of a row must be declared to be the unique key for the table. This is much lighter-weight storage than a SQL database but it comes with limited indexing and searching capabilities and no relational operations.
    • Queue storage – supporting the standard push, pop, and peek operations and perfect for the introductory example web/worker role communications
  • Azure Drives – this is actually a variation of blob storage where you upload an NTFS-formatted virtual hard drive (VHD) to your blob storage and then mount this as a drive in your azure role
  • SQL Azure – SQL database instances that you can create and use in your Azure cloud service roles
  • Azure Service Bus – this is a set of services that offers event messaging, queues, and message forwarding
  • Virtual Private Network – create a VPN that can be used by all of your Azure cloud service roles and can optionally connect to your local network

Azure Cloud Service Role Details

A cloud service role is composed of instances where you must have one or more running instances to be operational. This is one of the largest advantages of using Azure as a hosting provider. If the load on your application increases, you can add more instances simply by making a configuration change in the Management Portal. Azure handles the work of finding space for the new instances, starting them up, and configuring them in the load balancer. The load balancer will automatically distribute traffic to all of the running instances.

Azure cloud service roles have some unique characteristics that differentiate them from conventional on-premise servers.

  • Not domain joined – Azure roles are all stand-alone, thus there are no shared service identities; most intra-Azure communications is secured using shared secrets
  • Role instances run as VMs and can be stopped and restarted without warning by the Azure fabric controller in cases of hardware or other failure; for this reason:
    • Applications must be stateless or store state off-machine to Azure storage or SQL Azure
    • Conventional logging to files or the event log will be lost if the instance gets recycled; you can use an Azure library to log to Azure storage
  • Each instance is on the public internet by virtual of the load balancer mapping internal IPs to public IPs
    • There is a per-machine Windows firewall
    • Can use Azure VPN to connect role instances together if secure direct TCP communications is needed
  • Limited out-of-the-box configuration but can install and configure additional software by the use of startup scripts
    • The startup scripts run each time an instance is recycled or updated; thus a complex startup script will slow role startup
  • Can configure per-instance remote desktop for inspection and debugging

Azure roles are tightly coupled to ASP.Net. IIS is the default web server. You can choose the version of Windows Server you’d like to use. This also implies the version of IIS and the .Net framework. Azure currently offers the use of Windows Server 2008 SP2, Server 2008 R2, or Server 2012.

The Azure SDK extends Visual Studio with cloud service templates and publication support and provides a development simulation of the Azure run-time environment. Thus you can develop and test an Azure application on your desktop and then upload it to Azure all without leaving Visual Studio.

Next time: hosting a Shibboleth SP web application in Azure.

 

Dueling Federation Standards

The nice thing about standards is that there are so many from which to choose. That may be a cliché, but it certainly applies to federated authentication protocols. There are several widely adopted protocols in use including SAML, WS-Federation, OAuth and OpenID. The first two are based on SOAP (Simple Object Access Protocol) messages carried over HTTP and are OASIS proposed or ratified standards. The latter two are non-SOAP REST HTTP protocols and are standards-track but not yet standardized.

SAML stands for Security Assertion Markup Language. The OASIS standard is composed of a set of specifications for assertions, protocols, bindings, profiles, metadata, etc. There is a community developed, open source implementation from the Shibboleth Consortium that is in wide use in higher education and elsewhere. SAML version 1.0 was ratified as a standard in 2002. The current version 2.0 of the standard was ratified in 2005.

WS-Federation is part of the Web Services Security (WSS) set of proposed and accepted standards which includes WS-Trust and WS-Security. Microsoft and IBM both contributed to the design of the standards and employ them in their federation software. The Microsoft implementations use either SAML versions 1.1 or 2.0 security tokens. To the best of my knowledge there is no open source reference implementation.

Although both of these standards share the same token format, the wire protocols are not compatible so that interoperation is not possible.

OpenID is a newer identity federation protocol specification. It is rapidly evolving due to early versions having significant security weaknesses. Several major web vendors, including Google and Yahoo!, implement OpenID authentication systems.

OAuth is technically not a federated authentication protocol. Rather, it is an authorization framework. It is typically employed in situations where one user is granting limited access to his or her protected resources to another user.

OpenID Connect is a protocol framework that incorporates the features of OpenID 2.0 and OAuth 2.0 in an API-friendly fashion. It employs elements that are compatible with REST including JSON Web Tokens (JWT) for the transmission of user attributes (a.k.a. claims or assertions).

Each federation standard defines several roles or components and they all function in a similar fashion. First there is an identity provider (IdP) that stores and verifies user identities. Technically the IdP is the protocol layer that lies in front of an authentication system such as Open LDAP or Active Directory. An IdP is also known as a security token service (STS). Then there is the web application that requires user authentication. Such an application is known as a service provider (SP) or relying party (RP). The standards define the function and format of the IdP and SP components.

So, which of these is the best? Well, it depends. The SAML standard has a non-proprietary and proven implementation in Shibboleth and it meets the needs of most web applications. The WSS protocols are widely used in business software. There are some advantages to designing a web API using REST-ful conventions rather than SOAP. A REST-ful API precludes the use of a SOAP-based authentication mechanism. However, the OpenID technologies are immature such that implementations vary in their interpretation of the protocols and many have suffered from significant security vulnerabilities. Time will tell if OpenID authentication evolves into a trusted and widely used technology. Note: when a large business like Microsoft or Google or Facebook adopts a technology, that technology can become a de facto standard. In the case of OpenID, their versions are slightly different, so hopefully a real standard will emerge through the standards development process.

Federated Identity

Identity is a tough nut. We all know who we are but even in the physical world a raft of documentation is required to prove your identity to others. The Obama birth certificate is a perfect example of just how complex identity can be. In the virtual world the situation is much worse because of the ease at which bad actors can impersonate others. Even a casual user of the Internet will end up with identity information stored in multiple places protected by nothing more than a password. Your identities are only as safe as your passwords. A diligent person will use complex passwords and have different passwords for each web site/identity-store. This quickly gets unmanagable. Federated identity is proposed as a solution to this problem where you have a single identity provider which is trusted by other web properties to vouch for who you are.

That sounds like a great idea; one identity trusted by multiple services. The reality turns out to be a mess though because everyone wants to be that one trusted provider of your identity. To make matters worse there is no agreement on the protocols to be used for this identity federation. The aim of this blog is to discuss the pros and cons of the federated identity choices and to dive into security, privacy and programming considerations.