I explained how to create an Azure cloud service application web role in my prior post. Now I will discuss the steps and code needed to add the Shibboleth Service Provider so that the web site can use SAML for single-sign-on authentication.
Adding an SSL Certificate to the Azure Web Role
SSL is the first layer of defense for an SSO web application. Thus you must obtain an SSL certificate for your web site’s URL. This is a whole topic in itself, so I will skip the details of how to obtain an SSL certificate. The biggest trick seems to be configuring Azure and Visual Studio to not get confused between the remote desktop certificate and the SSL certificate. The Azure instructions for configuring SSL are here. I’ll summarize the most important points below.
- If you are creating a test web site, then a self-signed certificate will suffice. Make sure the certificate’s subject CN is set to your web site’s full DNS name. In this example that DNS name would be myshibbolethsp.cloudapp.net.
- You will need to have the certificate in a PFX file so it can be uploaded to Azure. This PFX file must contain the certificate’s private key! You will also need the certificate thumbprint.
- Modify the cloud service’s service definition and service configuration files as shown in the Azure article.
- There are actually two service configuration files, a local and a cloud version. They must both be updated to contain the SSL certificate.
- Note that the service configuration files will already have a listing for the remote destkop certificate. The SSL cert entry should be added to this <Certificates> section.
- You probably don’t want a non-SSL connection, so remove the HTTP binding and endpoint and replace it with the HTTPS binding and endpoint in the service definition file.
- Upload the SSL certificate to your cloud service application.
- Go to the Azure Developers’ Portal and click on your cloud service application.
- Click on the CERTIFICATES item at the top right of the window.
- Click the UPLOAD button at the bottom of the screen.
- This opens the “Upload certificate” dialog. Browse for your cert’s PFX file and enter the private key password and click the OK check button.
- Now the SSL-modified cloud service application needs to be uploaded to Azure.
- I got an error when I tried to upload the app using the VS Publish command: Certificate: ‘myshibbolethsp.cloudapp.net’ with Thumbprint: <…> for Role: WebRole1 has not been uploaded to the cloud service. I had previously uploaded the certificate, but that didn’t seem to help.
- Rather than use VS to Publish the app, you can upload the “deployment” package using the Developer Portal. This is the option described in the Azure article above. Perhaps there is a reason they explain doing it in this fashion.
- First you need to build the deployment package. In VS, right-click the cloud service project and choose “Package…”. This brings up a small dialog where the Service configuration should be set to “Cloud” and the “Enable Remote Desktop” checkbox should be checked. Click Package.
- Go to the Developers Portal and click on your cloud service application. Go to the DASHBOARD and then click the UPDATE button at the bottom of the screen. This brings up the “Update your deployment” dialog which is very similar to the “Custom Create” shown in the Azure SSL article.
- Click the FROM LOCAL button to browse to the package file you just built. It should be under your VS cloud service project folder in the bin\Release\app.publish folder.
- Do the same thing to locate the configuration file in the same folder.
- Make sure the “Update the deployment even if one or more roles contain a single instance” box is checked. Click the OK check button.
- You can check the progress of the deployment update from the Developers’ Portal.
- Browse to your web site using HTTPS. Fingers crossed! It should work but HTTP should be rejected.
Adding the Shibboleth SP to the Azure Web Role
This post assumes that you have a SAML IdP that will authenticate your test Shibboleth SP. If you need to set up a test IdP, Microsoft has produced a series of videos on how to do this. Of course there is the Shibboleth IdP documentation at shibboleth.net. You should also have downloaded the Shibboleth SP 64-bit Windows/IIS 7 MSI file. Get the latest version from the download site.
- Install the Shibboleth SP to your development machine or a local web server. You will need several of the configuration files and it would be best to understand how it works in a local installation. The UW has some great instructions on doing this install.
- You have to upload the Shibboleth SP MSI and related files to Azure. To do this, add the files to the VS project.
- In VS create a folder under the web role project. Call that folder Shibboleth-SP.
- Add the Shibboleth SP MSI file to this folder.
- Add a properly configured shibboleth2.xml file to this folder. More on this below.
- Add a certificate public key PEM file for the IdP’s metadata signature.
- Create a text file in this folder. Name it install-shib.cmd.
- You would also need an attribute-map.xml file if you are doing any custom attribute mapping.
- All of these files must have their “Copy to output directory” property set to copy-always. You can find this setting on each file’s Properties tab.
- Several changes must be made to the shibboleth2.xml file. There is one change that is rather mysterious. The site ID for the cloud service web role must be set to match the site ID in IIS. I found that Azure was setting the site ID to 1273337584. I have no idea why this particular number was used. I’ll discuss this further in my follow-up post.
- Modify the service definition file to run the install-shib.cmd startup script. Add the line
<Task commandLine=”Shibboleth-SP\install-shib.cmd” executionContext=”elevated” taskType=”simple” />
inside of a <Startup> element following the instructions from Microsoft.
- Last, but not least, you need to fill in the startup script. I’ll post the entire script in a subsequent blog post, but here are the notes about what it does.
- First, it runs the Shibboleth SP MSI in unattended mode. I am using the default install path which had to be explicitly declared in the version 2.5.1 MSI. I also specify that install logging goes to the temp folder. This article describes how startup logging works.
- It then copies files from the Shibboleth-SP directory to the SP install directory. This includes some DLLs that are in the path but that can’t be found by the Shibboleth ISAPI filter for some reason.
- The SP MSI relies on the IIS 6.0 compatibility API extension to install the Shibboleth ISAPI filter. The Azure version of IIS does not have this extension installed, so I use the appcmd utility to install and configure the ISAPI filter.
- Some file system ACLs are missing so I use the icacls tool to set them.
- Finally I restart the Shibboleth service daemon so it will pick up the new Shibboleth2.xml values.
- Now you can build and upload this new version of your Azure web application. At this point you should be able to use either method: publish from VS or update from the Developers’ Portal. Note that there is actually a third method that could be used. VS calls out to Azure SDK tools. You could use those tools directly in case you want to have a build script automate the upload and deployment.
Now when you browse to your Azure web site you should be redirected to your IdP’s login page. Once you successfully log in you should be redirected back to your web app. There will now be session variables that contain authentication attributes such as IdP URN, user name, and so on.
Simple, huh? More details to follow. I didn’t say this was going to be easy.