The Shibboleth V2 IdP and SP software have reached End of Life and are no longer supported. This documentation is available for historical purposes only. See the IDP v4 and SP v3 wiki spaces for current documentation on the supported versions.

Hosting Shibboleth SP in Azure

Owned by Eric Kool-Brown
Last updated: Jul 11, 2013
3 min read

I recently completed a proof-of-concept project to use the Windows IIS version of the Shibboleth SP on an Azure-hosted web application. I wrote a series of blog posts giving background information and detailing the required programming and configuration steps. The blog series is on my University of Washington blog at http://blogs.uw.edu/kool/. A short synopsis follows.

Azure Hosting

Microsoft's Windows Azure provides a variety of hosting options and services. One option is to upload a complete virtual machine that has been configured to run your web application. You can choose a different option, the Cloud Service, which provides the OS and IIS. The Cloud Service option is tightly integrated into Visual Studio such that you can build an ASP.Net web app and upload it directly to Azure. Once uploaded, Azure installs the app into IIS and starts it on the URL you have specified. Using the Shibboleth SP for authentication presents an additional hurdle; you must provide for the installation and configuration of the SP into the Azure web role.

Visual Studio App Project

The VS project specifies the files to be deployed to Azure. All of the web application files (the ASPX, code behind, images, style sheets, etc.) are automatically included in the deployment package. You can include additional files in the project. Thus you can add the Shib SP MSI to the project. You should also make the appropriate changes to the shibboleth2.xml file and add it to the project. The certificate public key PEM file for your IdP's metadata signature must also be included.  You need to specify that all of these files be copied to the output directory so that they will be included in the deployment package.

Azure Startup Tasks

An Azure cloud service web role provides a mechanism to customize the app environment. This can be done by creating a startup task. A startup task is run by Azure after your deployment bits have been copied to the web role instance but before IIS has been configured with the web app. A startup task is specified by adding a Task element to the service definition file. You can find an example startup task batch file at Code Details for Hosting a Shibboleth SP Web Site in Azure.

Test Web Site

You can find my POC web site at https://uwshibsp.cloudapp.net. It is currently using the UW IdP so only UW folks can log in. I hope to add a discovery service at some point to allow InCommon federated login.

Caveats

This project was completed in June of 2013. Azure is rapidly evolving. I will attempt to keep this information and the application up-to-date, but beware that Azure changes could affect the accuracy of this information.

Note that there are lots of rough edges in this POC app. The SSL cert is self-signed. The URL is based on an Azure domain. A real web app would need a URL that is based on your organization's domain. You would need a properly issued SSL cert for the app's URL. An Azure cloud service can be configured to use your organization's domain if you can prove ownership of the domain.

One Azure IIS configuration setting is not documented. The ID assigned to the site by Azure appears to be a random number. I did not observe this number changing, but it is unclear if this number could change at some point. The blog series discusses the site ID and the necessity of placing the correct one in the shibboleth2.xml file.