This is the last in a series of posts about using the Shibboleth Service Provider to implement SAML SSO authentication in an Azure cloud service web site. The first three posts present background information. There are two posts that are specific to using the Shibboleth SP with Azure and then there is this concluding post.
The information I am presenting has come from three sources. First is the official Azure documentation from Microsoft and Shibboleth documentation from the Shibboleth Consortium. Each discusses their respective areas but there is no overlap. My second source of information is what I learned while working on the Azure team at Microsoft. That was over a year ago and many things have changed in the interim. However, it gave me a foundation in understanding how an Azure cloud service works. Finally I did a lot of experimenting, trying things, seeing what worked and what didn’t. I’ve found nothing on the web about hosting the Shibboleth SP in Azure so I believe I am blazing a trail of sorts. I hope this information may be of some value to others. Having said that I must offer some caveats.
The first caveat is to simply underscore the fact that Azure is being updated by Microsoft at a frantic pace. My explorations that produced this web application were done in June 2013. Some of the details will certainly change or become obsolete over time. E.g. I noted that an Azure web site did not support SSL. I’ve since seen an announcement of an SSL preview for the web site feature.
Unresolved and Unexplained Issues
Mysterious Site ID in IIS
I used the remote desktop to look at IIS Manager on my Azure role instance and saw that the web site ID was 1273337584. I thought “it’s assigning a random number” and expected it to change with subsequent deployments. It didn’t. So I deleted the deployment and redeployed instead of just doing an update. It remained the same number. Then I deleted the entire cloud service and created a new one with a new name. The web site ID remained the same. What can I conclude from this? Nothing really. I don’t know if this is a fixed number, used for all web role instances (remember that each role instance gets its own VM, so there is no chance of site ID collisions), or if there is some algorithm that could be related to my subscription or some other value.
I looked into using appcmd to read the site ID assigned by Azure thinking I could then modify the shibboleth2.xml file on the fly. Then I discovered that the web site hasn’t been created at the time the startup script is running. The only option is to have a method override in my app code for the role start notification. This is a bit of a chicken-and-egg problem because I’d have to restart the Shibboleth service after updating the config file and might also have to restart the web site – from within the web site code. So this issue remains without a good resolution.
Azure Load Balancer Affinity
A SSO exchange involves several browser redirects first initiated by the SP code, then by the IdP code back to the SP. In between there is a user interactive log in. All of the Azure documentation stresses that your web applications must be stateless. If you have multiple instances of a web role running for load handling reasons, you have no control over which instance will receive a request. Will this cause problems during the authentication sequence?
I found one non-Microsoft blog post that said the Azure load balancer would have session affinity for a given source-IP/port pair. My own understanding from when I worked in Azure was that the load balancer would maintain a session for up to one minute of inactivity. I’ve seen no official confirmation of either notion. I’ve not spun up more than one instance yet to test this issue. Considering that Microsoft provides an SSO federation service in Azure’s Access Control Service, which uses the same sort of redirect sequence for authentication (more actually because of the extra federation hops), I’d have to believe that this is not an issue. It would be nice to know for sure though.
Of course this begs the question: why doesn’t Microsoft natively support SAML authentication? That is, why isn’t there a Windows Identity Foundation protocol handler for the SAML profiles and bindings? That would eliminate the need to jump through these hoops. I’ve asked some of my former Microsoft colleagues who are in a position to know and have received no response. I know the official line is to not comment on unreleased products or product plans, so the lack of a response is not surprising.
There is also the option of updating the Shibboleth SP implementation so it can act as a WIF protocol handler. It is open source and community developed. I might be able to contribute. Stay tuned.