Share-n-dipity

SharePoint serendipity is the effect by which one accidentally discovers something fortunate, especially while looking for something else entirely. In this case, it is the occassional musings, observations, and Ouija board readings about the phabulously

The Azure Custom Claim Provider for SharePoint Project Part 1

The Azure Custom Claim Provider for SharePoint Project Part 1

  • Comments 1
  • Likes

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.

Comments
Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment