Hosting a Shibboleth SP Web Site in Azure, Conclusion

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.

Conclusion

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.

 

8 thoughts on “Hosting a Shibboleth SP Web Site in Azure, Conclusion

    1. Eric Post author

      Hi Armin,

      Well it has been nearly a year and I haven’t had a chance to try the KentorIT SAML SP. I note that it appears to be under active development which generally is a good thing. I also see they have an OWIN middleware layer. I haven’t looked closely but my curiosity is now piqued. If you give it a try let me know how it works out.

      Eric

      Reply
  1. Gilberto Verastegui

    Hi, i’m currently working with a Customer that wants to authenticate their LMS (Blackboard) for all the students with ative directory, they have Office 365 and of course Windows Azure Active Directory, but they do not want to purchase all students active directory license (about 19000 licenses :S). My questions are what IdP did you use with your shibboleth authentication? did you explore the Windows Azure Active Directory as IdP?

    Reply
    1. Eric Post author

      Hi Gilberto,

      It seems like you are asking about two things: technologies and licensing. WRT licensing, we have an Enterprise agreement with MS that covers all of the UW population for on-premise AD and we also have an EDU Office 365 agreement which gives us basic AAD licenses for all of our folks. We have extended the Office 365 agreement to include a batch of AAD Premium licenses so we can test out MFA, MDM and RMS.

      As to the technology, we don’t sync passwords to AAD which is why we use ADFS. We use our Shib IdP as a Claims Trust Provider for ADFS which gives all of our campus SSO the same UI experience. There may be reasons to sync passwords to AAD in the future, but we haven’t crossed that bridge yet for a variety of reasons.

      Eric

      Reply
  2. Justin

    Eric,

    Having been a year since you posted this would you make any updates or changes to how it was implemented, also considering any new authentication methods the UW is offering or considering offering?

    Thanks
    Justin

    Reply
    1. Eric Post author

      There is a new development that I haven’t had a chance to explore. It is https://github.com/KentorIT/authservices, an open-source SAML authentication extension for an ASP.Net web site. I think this code could be added to an Azure web site which would eliminate the need for the complex cloud service pre-install of the Shibboleth SP I had rigged up. I’ve got it on my back burner to give the Kentor code a try at some point.

      I should note that Shibboleth is the reference SAML implementation. I don’t know how well the Kentor code implements the SAML protocol. As we all know, a bug in a security protocol implementation is a “really bad thing!”

      Eric

      Reply
  3. Matthew Rich

    Hi Eric, this is really great stuff. I’m a software developer at Northwestern University, also part of InCommon, and I’m looking at hosting my web apps in Azure using InCommon’s Shibboleth SP for authentication. However I’m not very experienced in the IAM world, being mostly a web developer. Is there any chance I could reach out to you with some questions? Like for starters, does the information in your blog posts still hold true for Visual Studio 2013 and MVC5? Thanks!

    Reply
    1. Eric Post author

      Hi Mathew! This should work for any IIS web site type that can be deployed from Visual Studio. The Shibboleth Service Provider is an IIS pipeline filter. It doesn’t require any changes to the web site code. I don’t see how the VS version would matter either.

      Reply

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.