Extending SharePoint Online with Windows Azure

As customers move to O365 and SharePoint Online (SPO) and begin to realise the benefits of public cloud, they typically look to expand the scope of their cloud deployment further and often extensions to SharePoint is the most obvious place to look. after all – if,  you’ve taken the decision to move your SharePoint deployment to the cloud, why wouldn’t you want to host extensions to it there too? Windows Azure simply makes perfect sense in this case.

There are various ways in which Azure can be used to enhance SPO, amongst them –

  • One can serve data through Windows Azure (from SQL Database, for example) which can be displayed in SPO as an ‘external lists’
  • One can host a process on Azure, typically as a Worker Role, that would read and/or write from SharePoint lists alongside some other processing
  • One can surface a custom application, deployed on Windows Azure, through the SPO UI

In this post I want to demonstrate how simple it is to do the latter, and to make it useful ensure that I’m adding Single-Sign-On to the mix.

To start with, I deployed a vanilla ASP.net web role project onto my subscription.

Browsing to the newly deployed cloud service looks like this –


On SharePoint online, I went to our team’s site and added a new page so that I can experiment with without getting on anyone’s nerves 🙂


On the page that was created I added a ‘Page Viewer Web Part’ and in the part’s properties I set the URL to my cloud service


The result was the Azure content displayed within the portal


Note: one side-effect is a warning by IE (“Only secure content is displayed”) which has to be acknowledged in order for the Azure content to be displayed. This is due to the fact that SharePoint Online is served over SSL and my web role isn’t. adding a valid SSL endpoint to my web role avoids this issue (but may cause another if you’re indeed using a self-signed certificate ;-))

So – considering that my Windows Azure deployed application could have been something actually meaningful and useful, it’s handy to know that serving that through the corporate portal on O365 is a nice-and-easy (circa 10 minutes!), but of course, as I mentioned, to be a realistic scenario I also had to make sure I plumb it all to our identity scenario ensuring that my Azure-based application can be secured without hassling the users to authenticate again.

In our case SPO uses ADFS against our on-premises AD, and that model, not-surprisingly, maps very well to Windows Azure.

In order to integrate my Windows Azure based application with ADFS I started by creating an Access Control Service Namespace and in that I had added our ADFS as an identity provider. this takes a few minutes to set-up requires access to the ADFS metadata (URL or file) as well as setting up ACS as a relying party in ADFS. it is also important to add at least one claim rule to ensure ADFS actually emits some claims to ACS and through that to your application.

With the ACS->ADFS link done it was time to add my application as a relying party in ACS and generate/configure the rules for the claims, in my case I was happy to pass the claims from ADFS as is, but I also, for testing purposes, add rules to populate the name output claim with the windowsaccountname claim from ADFS.

With all the configuration done it was time to integrate my application with ACS, which is easily done using the Identity and Access tool in Visual Studio,  selecting my ACS namespace and identity provider I configured earlier and I was pretty much ready to test my setup.

To be able to verify the sign-in worked I added a couple of controls to my page that will confirm the user is logged in and will display the user-name.

   <asp:loginstatus ID="Loginstatus1" runat="server"></asp:loginstatus>
    <asp:LoginName ID="LoginName1" runat="server"/>

I went ahead and tested it straight on Windows Azure. if you choose to test it locally first (which saves the deployment time) be sure to update the configuration with the correct (local) Application URL, and then change it again when deploying to Azure.

Sure enough, with the federated identity configuration in place, browsing to my application from within our corporate network provides me with a seamless single-sign-on experience and my login-details appear on the frame within the SharePoint page.

Outside the network I can still get to SharePoint Online and to my application, but I am required to enter my credentials the first time around, which will then be cached according to the settings in my application configuration file and ACS.

All of this means not only that I have secured access to my Windows Azure based application by requiring authentication and that I made it easy for my colleagues by employing Single-Sign-On with our corporate identity, I can, of course, now use standard .net mechanism to manage authorisation across the application 

%d bloggers like this: