Hi all, it’s been a while since I’ve added new content about SAML claims, so I decided to come back around and write some more about it in a way that links together some of my favorite topics – SharePoint, SAML, custom claims providers, the CASI Kit and Azure. This is the first part in a series in which I will deliver a proof of concept, complete with source code that you can freely use as you wish, that will demonstrate building a custom claims provider for SharePoint, that uses Windows Azure as the data source. At a high level the implementation will look something like this:
- Users will log into the site using SAML federation with ACS. On the ACS side I’ll configure a few different identity providers – probably Google, Yahoo and Facebook. So users will sign in using their Google email address for example, and then once authenticated will be redirected into the site.
- I’ll use Azure queues to route claim information about users and populate Azure table storage
- I’ll have a WCF application that I use to front-end requests for data in Azure table storage, as well as to drop off new items in the queue. We’ll create a trust between the SharePoint site and this WCF application to control who gets in and what they can see and do.
- On the SharePoint side, I’ll create a custom claims provider. It will get the list of claim types I support, as well as do the people picker searching and name resolution. Under the covers it will use the CASI Kit to communicate with Windows Azure.
When we’re done we’ll have a fully end to end SharePoint-to-Cloud integrated environment. Hope you enjoy the results.
In Part 2, I walked through all of the components that run in the cloud – the data classes that are used to work with Azure table storage and queues, a worker role to read items out of queues and populate table storage, and a WCF front end that lets a client application create new items in the queue as well as do all the standard SharePoint people picker stuff – provide a list of supported claim types, search for claim values and resolve claims.
In Part 3 I create all of the components used in the SharePoint farm. That includes a custom component based on the CASI Kit that manages all the commnication between SharePoint and Azure. There is a custom web part that captures information about new users and gets it pushed into an Azure queue. Finally, there is a custom claims provider that communicates with Azure table storage through a WCF – via the CASI Kit custom component – to enable the type in control and people picker functionality.