SharePoint Authentication Fun

April 16, 2009 04:59 PM

While I have a backlog of blog posts I need to write, this one just hit me, and seems interesting (also, maybe I can get some additional insight).

The fact that SharePoint uses ASP.NET's forms-based authentication system is very nice. It means you can tap into almost any sort of authentication scheme you want, rather than being bound to Windows logins or Active Directory.

On the other hand, forms-based authentication doesn't play well with applications that aren't web browsers. (This is, incidentally, why SharePoint gives you the option to turn off client integration.) Pretty much any application that can download data from the web recognizes a 401 status code--but it can't tell the difference between a login page and the content you were expecting.

You might have encountered this if you've tried to open a Word document from a FBA-secured SharePoint site. If you're lucky, Word will use IE's authentication cookie and work seamlessly. If you're not lucky (and you usually aren't), you end up with the login page as a Word document. Which is, to say the least, not particularly helpful. (I think I read that this is being addressed in Office 2010, but I can't remember where, so it's possible I'm just making this up.)

Anyway, membership providers. They provide a great deal of flexibility. But they can also box you into a corner in terms of expectations, since most SharePoint-enabled applications assume you're using Windows/Active Directory logins.

As an example, we have the following situation on a SharePoint project I'm currently working on:

Most users will access the site using forms-based authentication (because of other authentication requirements). However, they also have an Active Directory account that they can use to access the site through an alternate access mapping.
Other users do not have an Active Directory account at all. They will have to access sites via FBA backed by a plain old ASP.NET SQL membership provider (or something similar).
A key requirement of the project is that data be downloadable for offline use (via products like Geo-Replicator or Colligo Reader--it's not been decided which) for all users. Both of which require an AD login to sync data.

I'm not complaining, of course, because these aren't really pie-in-the-sky requirements that are conflicting. They are all necessary to the product being both useful and secure. But the balancing act is somewhat mind-boggling, because every choice requires some difficulty on the users' part.

So it's sort of a stalemate. We could in theory keep our options open on the offline use requirement, but it would require setting up a separate AD domain for external users (which is both a maintenance nightmare, and potentially impossible because of security requirements). Or, we can stick with FBA for our external users, which cuts out some of our options for offline-SharePoint products. (Although, interestingly enough, it doesn't negate all of them.)

I'm going with the latter, which feels like a hack in certain ways, but it meets all the requirements, satisfies them all as much as possible, and doesn't overly complicate things as part of the compromise.