Click Mice, Unclick Mice

If you have been keeping track of Windows Live ID (formerly known as Passport) at all, you should have seen the announcements about the Windows Live ID Web Authentication SDK being released.  I was pretty happy to see this myself.  I was a member of their beta program because I was interested in how this authentication would work with SharePoint.  So I gave myself a weekend project.  I decided I would write a SharePoint Windows Live ID Membership Provider.  While I was in the middle of developing the Membership Provider, I found I needed to also create a Role Provider to ensure that I met all of my requirements.

 

I am in the process of creating a SharePoint solution to allow others to make use of the providers, however as I finish that up you might be wondering how it all works.  Well, the easy answer is to click on the Sign In link in the upper right hand corner of this page.  It will step you through the login process.

 

The Membership and Role providers are linked in to the SharePoint Forms Based Authentication (FBA) architecture.  This means that the Sign in and Sign Out mechanisms are integrated right in to SharePoint automagically.

 

When you click the Sign In link you will be redirected to the Windows Live ID login site.  This site validates the users credentials, either by requiring them to login with their Live ID credentials or by validating that they have an active Windows Live session.

 

Once the Windows Live session is validated, the Live Login system will redirect you back to SharePoint.  The Windows Live system requires an Application Administrator to register a single URL per application ID to return users to once they have been validated.  The Windows Live request returns a signed authentication token that the SharePoint server verifies, and then uses to identify the user by their unique user token.  This token is unique to each Application that is registered to the Windows Live system.  What this means is if I register an application for blog.solanite.com and one for moreblogs.solanite.com I will get a different ID's for the same Windows Live ID on each system.  These unique user tokens only provide the SharePoint server with validation that Windows Live has authenticated this user.  It does not provide access to the Windows Live associated email, or really any information about the user.

 

When the Windows Live system responds to SharePoint, the user token is checked against the profile store.  In the case of what I have written, I decided to test Microsoft's statement that with the performance tweaking abilities added to SharePoint, you can technically use a SharePoint list instead of using a SQL table for simple applications.  I just did a few web searches, and can't find any published versions of this statement, but it is something I and others I know have heard several times.  I have set the user token and email columns of the profile list as indexed to help with searching against them, and I am hopeful that I'll see good results as the number of profiles increases. 

If this user token is new, the user is prompted to enter an email identifier.  This is done to help with adding users to SharePoint sites.  Remembering a long user token is difficult to do, however typing in an email address is much easier.  The profile store itself is not accessible, unless you have specific access to the list so the data is protected.

 

Once either the new user has submitted an email address or the pre-existing user check is completed, you are redirected back in to the SharePoint page you initially signed in from. 

 

As I was working with the Membership provider I realized I was going to want to be able to add the equivalent of NT_AUTHORITY\Authenticated Users to a SharePoint site.  The answer was to create a Role provider that implemented one role, Authenticated Live Users.  This solved my primary issue, and allows someone to invite all Live users to a site.

 

This is not a perfect system, however it does accomplish what it is should.  Some of the major issues come from the Windows Live ID system itself.  It does not share the email address of the Windows Live ID with the application, so in order to get a human readable identifier for the user they must be asked to provide an email (which is less than ideal). 

Another issue is how the Membership provider works.  When using WSS (not MOSS) users added from a Membership provider get a display name that is the same as their UserName in the provider.  There isn't a way to acquire a Display Name automatically, which leads to the next problem.  Users can't change their profile information in SharePoint unless they have contributor access to the site they are currently in (by default at least).   I understand the reason behind it, but it is still annoying in this particular case; however, the solution is pretty simple by adding the Edit Personal User Information  permission in to the Read permission level.  Since we have the Authenticated Live Users role then all Live users can be added with Read access.

 

My intention is to finish up the solution sometime yet today or tomorrow, and let a few people I know test it out to make sure it installs smoothly.  Once it seems to be working well on their systems, I'll put it up for download assuming there is interest.  If you are interested and want to help out, feel free to give the Live integration a shake down on this site.  Please leave any comments and suggestions here.  I am happy to hear about the things you liked and the things you didn't.