If you’re exploring how to leverage Forms-based Authentication for your SharePoint Extranet, chances are you’ve run into the ASP.NET SQL Membership Provider. Aside from the MSDN link I just pointed to, you’ll probably find countless tutorials about it online, as well as a few open-source products (such as the CodePlex SharePoint FBA Pack) and other commercial products I won’t name here for obvious reasons.
However, while this ASP.NET membership provider is widely used in SharePoint FBA scenarios, it has inherent flaws that I’ll try to highlight here. For the sake of clarity, I’ll group those weaknesses in 3 different buckets: installation/configuration, usability and (probably most importantly) security. So if you’re thinking of using it for your SharePoint extranet, think twice and read on before making any hasty decision.
Installation & Configuration
As you’ll soon find out, setting up a SharePoint FBA environment with the ASP.NET Membership Provider is a fairly long, tedious and error-prone process that at least involves
a) setting up the so-called “ASP.NET database” (for lack of better name, I guess),
b) adjusting database security,
c) modifying at least 3 web.config files (in the “best-case” single web front end scenario) and
4) configuring your web application’s FBA provider
If you miss out one single step or simply perform one incorrectly, prepare yourself for a few sleepless nights and frustrating troubleshooting sessions!
Furthermore, any further configuration modification (such as modifying the password strength or enabling security questions) will require you to sign in to each of your SharePoint front-end server and perform the same modifications in each web.config file, because that’s where the ASP.NET membership provider stores all its parameters. Not exactly administrator-friendly, is it?
There’s actually a reason why FBA software vendors will also try to sell you installation & configuration services on top of their software licenses and that’s simply because installing the ASP.NET Membership provider still involves a lot of manual (and did I already say error-prone?) steps.
But let’s assume you’re an FBA black belt master and you literally nail that part. Or that you’re ready to put in the hours on this one, because, hey, it’s free, isn’t it? (your time is not though, but shhh… don’t mention it to your boss!). If that’s the case, brace yourself for the next 2 sections…
You’ve now successfully configured the ASP.NET Membership Provider in your SharePoint farm, so it’s time to celebrate and drink up some champagne!
Huh… not quite that fast, if you don’t mind me ruining your party.
Indeed, your venerable colleagues from marketing, sales and basically any non-IT department have been raised on Active Directory Kool-Aid since they were born (in the corporate world, I mean). And having been spoiled with Active Directory unavoidably creates high, if not unreasonable, expectations. Some of those seemingly high expectations are: user full name resolution and wildcard group search.
Alright, I know, you have no clue what I’m talking about here, so let’s illustrate those 2 requirements with a few screenshots:
The screenshot above illustrates what I call “user full name resolution”: in essence, you type the first few letters of a first name or last name and the SharePoint People Picker gives you search matches (aka “resolves” your search word) in an intelligible format you’re used to with Active Directory, which is… the full name of the user.
You would probably expect exactly the same usability feature when searching your external users stored in your ASP.NET database… but you’d be mistaken! Here’s what you would typically see instead:
I guess you could call that “user name resolution” (the People Picker search results only display the usernames of your external users), but I will can it just poor user experience. Why? You may make sense of those user names because you’ve aptly picked them to match either the first name of the last name of your external users, but try to imagine for one second the same user interface with hundreds or even thousands of external users in your database… Do you picture it now? I’d bet it’s not pretty…
On a side note, that poor user experience is one of the reasons you’ll see strong suggestions from consultants and vendors alike to assign emails as user names (even though there IS also an email field in the ASP.NET database…), simply because they assume that you can more easily recognize a user by her email address than by a random user name. And if your external users complain that they always have to type in their long email addresses in order to sign into your SharePoint extranet, please just ignore them…
When it comes to picking external groups, here is what your colleagues will expect (again, too much Active Directory Kool-Aid is the culprit here):
Nothing too much out of the ordinary, right? You type the first few letters of an external group of users and you expect to quickly see a list of matching groups (by name). Doesn’t sound too unreasonable, does it? Well, don’t be so trusting. With the SQL membership provider, here’s what you’ll see instead:
Nada. Zilch. Über-nothing!
In order to start to see something (or to be accurate, one single thing), you actually have to type exactly the whole name of your external group, without a single typo or extra blank space:
So long for the wildly touted increased user productivity and usability… Prepare yourself for sub-par, 1990′s-like user experience instead with your SQL MP-powered SharePoint extranet…
Not convinced yet? Read on, because I’ve saved the best for last…
You see, the SQL membership provider is not only a pain to configure and a piece of software from the Soviet era when it comes to usability, it’s also a huge security liability once you start doing some meaningful collaboration with your external users, such as working on projects and tasks. The main issue is that all your external users are by default visible in the SharePoint People Picker to other external users (they’re also all visible to your internal users, but that’s usually less of a problem – though it can be in large organizations!).
What does it practically mean? Let me take a concrete example to illustrate my claim here: imagine you have 2 separate partner organizations you’d like to collaborate with on your extranet. For the sake of clarity, let’s call them Contoso and AdventureWorks and let’s imagine each of those 2 partner organizations has a dedicated site on your extranet (or, more preferably, a dedicated site collection).
Now, imagine you’d like to let your Contoso users create or update tasks in a Tasks list available in their dedicated site (collection).You’ll soon realize they will be able to find and pick not only other Contoso users but also AdventureWorks users, which obviously should be a big security red flag for you, and a huge privacy liability for your employer!
Unfortunately, there isn’t really a good solution to that problem. You might find recommendations to restrict your “Assigned To” field (and more generally any Person field) to a specific SharePoint group, but that means you now have to assign each and every external user to that group (if they need to). Assigning external groups to that SharePoint group (and hoping to benefit from group inheritance) is not even enough, because in that configuration, the People Picker will require that the users be explicitly added to said SharePoint group.
You might also find recommendations to lock down the people picker to only search and resolve the site collection users, but the immediate consequence of that choice is that your site collection administrators will no longer be able to add additional users to your SharePoint sites… Isn’t that great, too?
Don’t say you haven’t been warned. If you want to move on and still use the SQL membership provider, you know which harsh realities you’ll have to face sooner or later. And if I’ve managed to convince you, sign up to download Extradium and discover how we are addressing all those installation, usability and security issues.by