SharePoint 2010 FBA and Claims

Slalom Consulting Justin Fentress

Slalom Consultant Justin Fentress specializes in designing and developing SharePoint and .NET solutions.

Background
For one of my clients, the need arose the have an implementation of SharePoint 2010 be externally available to allow access to both internally authenticated and externally authenticated users. Without spending a lot of time diving into the requirements, the implementation entailed the SharePoint farm living on an external domain; Active Directory Federation Services (ADFS) was setup to allow access to internal users, and Forms Based Authentication (FBA) was implemented to authenticate external users.

While ADFS is not the focus of this blog and, while I was not involved in its implementation, I will say that from my understanding it is simply a link to a specified activity directory, with some limitations. And what I mean by limitations is:

  1. ADFS does not appear to be able to synchronize with every field stored in AD;
  2. The out-of-the-box (OOB) ADFS Membership Provider stores the user’s email address as the user’s ID and Display Name in SharePoint; and
  3. The OOB ADFS Claims Provider returns all searches in the People Picker control as valid, even though the only truly valid account is a user’s email address (i.e. enter “The Moon is Blue” and the People Picker returns it as a valid result).

SharePoint 2010 FBA and Claims

However, unlike with SharePoint (MOSS) 2007 which enabled FBA using Classic Authentication, implementing FBA in SharePoint 2010 with the requirement of enabling Claims Authentication ended up being quite a bit more challenging, for three primary reasons:

  1. External users were authenticated against a 3rd-party application which exposes user validation and information retrieval via web services;
  2. The 3rd-party application utilizes case-sensitive usernames and SharePoint uses case-insensitive SQL storage (meaning in SharePoint usernames are stored as lowercase); and
  3. The OOB FBA Claims Provider displays the username as both the ID and Display Name in the People Picker.

FBA Authentication via Web Services
For those of you who have dabbled in SharePoint 2007/2010 FBA, you probably started out like I did by creating a SQL membership store, implemented a connection string in the web application’s web.config file, and let SharePoint’s OOB membership provider handle user validation and user information retrieval. Well, one thing that you’ll quickly find out when breaking this mold and implementing authentication via web services is you will now have to create a custom membership provider to handle all these requests. Instead of recreating the wheel on how to do this in SharePoint 2010, if you wish to know more about creating a custom membership provider, Adis Jugo’s blog Developing a Custom Membership Provider describes the process in detail.

While the article above utilizes hard-coded credentials in their demonstration, creating your own membership provider allows you the flexibility around your authenticate model, whether that is storing user information in SQL, utilizing LDAP, or accessing web services (as in my case). Even though this process will vary based on your needs and what information & methods are provided by external authentication services, implementing a custom membership provider is fairly straight forward.

FBA & Case-Sensitivity
While everything up to this point hasn’t caused any drastic ripples to rock the boat, here is where we hit our first “sink or swim” moment. As mentioned above in the background section, SharePoint uses case-insensitive SQL storage and consequently does not support case-sensitive membership providers. Unfortunately, this means if a case-sensitive username is the only “unique” identifier you are being provided, there is not a lot you can do.

EXAMPLE:
External Application

  • User 1 has a username of: MyTestAcct
  • User 2 has a username of myTestAcct

SharePoint

  • Upon storing the usernames, SQL converts the name into its lowercase form, which in both cases is: mytestacct
  • This in turns makes it so when User 1 or User 2 signs into SharePoint using their external usernames, SharePoint treats them both as the same user.

Fortunately in my case, there are numerical IDs being stored in the external application which I was able to utilize to uniquely setup and identify SharePoint users. Problem solved, right?

As I am sure you have surmised, while having the unique, numerical ID did get me around the case-sensitivity issue, there is a slight drawback. The custom membership provider utilizes a MembershipUser object when creating a new user in SharePoint. This object tells SharePoint to use the same property (username) when storing a user’s Login Name and Display Name. Given that people aren’t going to be standing around the water cooler asking if they got the memo that colleague 133428 sent out, I had to head back to the drawing board.

SharePoint 2010 FBA and Claims

SharePoint 2010 FBA and Claims

Now my first instinct after I create the MembershipUser object was create a SPUser object by calling web.EnsureUser(memUser.username). While this does contain a name and email field, ultimately it is limiting because there are so many other fields that could be populated. With this in mind, after some searching, I came across the hidden User Information List. This
list contains the user’s display name, work email, first name, last name, title, phone, and much more: http://<site collection>/_catalogs/users/simple.aspx.

SharePoint 2010 FBA and Claims

SharePoint 2010 FBA and Claims

So as you can see in the screenshots above, with some additional tweaks to the custom Membership Provider you can have your SharePoint user information updated and correctly displayed so a user sees their name when they log onto a site instead of just an impersonal number. But even once this has been implemented, there is still one more battle to face, the People Picker…

FBA & the People Picker
The People Picker is a great, easy-to-use tool as long as you are utilizing Classic Authentication. As soon as you enable Claims, the People Picker changes how it operates as it now needs to take into account the possibility for multiple avenues of authentication (Windows, FBA, ADFS, and Custom). Cern McAtee’s blog Understanding People Picker and custom claims providers to see a full breakdown of how the People Picker operates based on the authentication method.

Now I can’t fully blame the People Picker, because as it turns out the OOB Claims Providers cause a fair amount of the heart-aches felt when using the People Picker. As mentioned in the article above:

“A claims provider lists, resolves, searches, and determines the “friendly” display of users, groups, and claims in the People Picker when claims-based authentication is used. If your Web application uses claims-based authentication, you must decide whether to use one of the default claims providers or create a custom claims provider that will meet the business needs of your organization.”

In the case of FBA, even when you are correctly populating the User Information List (UserInfo table), the OOB FBA Claims Provider completely ignores this information and always lists the user’s login ID as the Display Name. So now we face an issue where we might not be able to identify user accounts being shown in the People Picker.

Note: This issue applies to both a numerical ID as well as a standard usernames as people many use abbreviations, nicknames, or random characters when creating a username.

SharePoint 2010 FBA and Claims

As such there appears to be two viable options:

1) Create a custom Claims Provider
It goes without saying that this process can get very complicated very quickly. There are some great articles out there on how to create a custom Claims Provider, one of which I have listed below. One note of caution is that you need to be careful and take into account all possible scenarios that will access your Claims Provider. Otherwise, you could see serious SharePoint performance degradations and the potential to bring down your entire farm.

Articles:

2) Modify the email field
When you are creating your MembershipUser object, one of the primary fields you populate is the email address. Now this field doesn’t show in the default view of the People Picker, but once you change the dropdown in the top-right to say List View, you can then view the email address.

How this helps us is that you can create a custom email format for the MembershipUser object that contains the user’s display name: [Last Name], [First Name] <[Email]>

Note: It is very important that you enter the name as “last name, first name” or SharePoint will throw errors that the email format is invalid

SharePoint 2010 FBA and Claims

One thing of interest is that when using the automated process to send a welcome email via the People Picker, I have seen inconsistent results at my currently client. If adding a user directly to Site Permissions (not best practice), it sends the email. If adding a user to a SharePoint security group, it doesn’t send an email. I haven’t been able to determine if it is a fluke due to emails server configurations, but it is something to keep in mind. However, if you aren’t going to create a custom Claims Provider, you don’t have many other options.

In the same way you update the User Information List to contain the correct display name, you want to be sure you update the email field to contain the correct address to ensure alerts work as those are tied to a SharePoint user’s stored information, not what is shown in the People Picker. If you don’t update the field, the SharePoint user information will display what is shown in the People Picker.

Note: If you are interested knowing the details concerning my work-around, you can find the code broken down here.

Summary
SharePoint 2010 offers some great OOB options to accommodate external (non-Windows) authentication models. However, as with anything created for general consumption, the OOB functionality might not be a best-fit for all situations. Fortunately there are multiple levels of customizations that can be implemented from creating your own Membership Provider to writing your own Claims Provider. When pursuing custom implementations, the best advice I can give is to leave no stone unturned by constantly ask yourself “what if… ”. This way you are fully prepared for any request/action that calls your custom services.

Slalom Consulting’s Dallas office Slalom Consulting's Collaboration focus
Learn more about our Dallas office Learn more about Slalom Consulting Collaboration

subscribe by emailSubscribe to follow new SharePoint posts

About Justin Fentress
Slalom Consultant Justin Fentress specializes in designing and developing SharePoint and .NET solutions.

5 Responses to SharePoint 2010 FBA and Claims

  1. Sasha says:

    Hi Justin,

    I red your article and we have the problem with the All Search Results pane like you have it on your screenshot above. It looks that the user belongs to Organizations but on the right hand side the user belongs to Forms Auth. Please let me know if you have any idea why the results are inconsistent.

    Thanks,

    Sasha

  2. Hi Justin,

    I am developing an app for a client, and they want first and last names displayed everywhere instead of the login name provided by the OOB SQL membership store. After reading your artcle and doing some research on my own, it seems that the only way to display anything other than the login name is by using a custom membership provider. Is this the case?

    Thanks,
    Mike VandeBerg

    • Justin Fentress says:

      Hi Mike,

      While I haven’t personally worked with the SQL membership store, from my understanding there are two best practice options for your situation. The first, as you mentioned, is to create a custom SQL membership provider so that you can handle the calls and update SharePoint profile information. The other option is to create a custom people picker to better display user information, but I am not sure the level of effort that is required for this compared to a custom membership provider.

      • Thanks Justin, Luckily my client already has the full name in the SPUser.name property through their custom membership tool. I think I dodged a bullet here! 🙂

  3. M Math says:

    Hi Justin,
    do you know how the people picker can be configure/customized in order to use list view by default instead of detailed view ?

    Thx

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: