In SharePoint 2010 and 2013, the People Picker has at least 4 major limitations when used in conjunction with Forms-Based Authentication:

1. User Search can only be performed on user names or emails
2. User Search only returns user names
3. Group Search does not support wildcard search
4. User confidentiality and segregation is usually not guaranteed

Let’s take a closer look at each of those limitations.

1. User Search Limited to User Name and Email Properties

Unlike a search on Active Directory users, searching an FBA user through an “out-of-the-box” FBA provider (such as the ASP.NET SQL Membership Provider) is limited to searching by user name or email address.

This is because the MembershipProvider class only provides FindUsersByEmail and FindUsersByName methods which, in most cases, only perform wildcard searches on email or user name, respectively.

This is an issue when neither the user name nor the email address are obvious or contain an easily identifiable property of the user, such as her first name or last name. It is also a cumbersome way of searching for users, since people tend to remember each other by their first names and last names, not user names or email addresses.

2. User Names Displayed in Search Results

Unlike a search on Active Directory users, the SharePoint People Picker will only display the user names of the FBA users returned by the search query and no other potentially interesting information about the user.

This issue stems from the fact that the ASP.NET membership provider used by any FBA implementation will always return a limited amount of information to the SharePoint People Picker. That information (contained in the MembershipUser class) includes the user name and email properties of the FBA user, but the People Picker only knows how to display the user name property.

Consequently, this makes it difficult to identify who the searched users are, especially when matching user names are close, cryptic or non-obvious. These issues can be compounded by the fact that there can be a large number of matching results, making it even more difficult and time-consuming to identify the user(s) that must be selected.

In practice, most SharePoint FBA solutions will recommend using emails as user names, but that recommendation is mainly based on the assumption that users are easily identifiable by their email addresses (which is not always the case), and prevents external users from using a short, convenient user name when logging in, thereby affecting the usability of FBA-enabled SharePoint sites.

On a side note, most FBA solutions only allow external users to sign in with their usernames, while Extradium allows users to sign in with their user name or email address, for additional flexibility and usability.

Consider the following example: in the list of Extradium users below, notice the 2 “John” users (john and john2).

When searching for “john” in the People Picker, here is a screenshot of the search results screen:

There is of course no way to know which one is John Doe or John Smith, unless you are able to look up the list of all FBA users on another screen.

The search results interface of the SharePoint People Picker is thus highly impractical when used with Forms-Based Authentication, especially when the number of FBA users is significant and the potential of a large number of matches on a single search term dramatically increases.

3. No Support for FBA Role/Group Wildcard Search

One of the most puzzling and frustrating “feature” of the People Picker with FBA roles (or groups) is the requirement to type the full name of the FBA group for it to resolve.

Unlike searching for Active Directory groups, this behavior is due to the fact that the People Picker relies on the RoleExists method of the RoleProvider class. That method returns a boolean, allowing the People Picker to resolve the typed search term or not.

In essence, the People Picker can only resolve one FBA role/group at a time, but the requirement to type the full group name is unintuitive, especially for SharePoint administrators and users accustomed to wildcard search. This is especially bothersome when FBA group names are long and cannot be shortened because all permissions that they were previously assigned to are lost as a result of the renaming.

Consider for instance the following scenario with long group names, such as “AdventureWorks Administrators” and “Contoso US Users”:

Typing “adventureworks” or even “adventureworks user” will not resolve to any group.

You actually have to type “adventureworks users” for it to resolve:

4. User Confidentiality and Segregation

This is by far the least well known and most challenging aspect of the People Picker when used with Forms-Based Authentication. And because it is quite a thorny and complex issue, we will address it in a separate blog post.

5. (Temporary) Conclusion

Of course, you probably wonder what the point of this blog post is if the only thing I’m doing is to pinpoint People Picker limitations without providing any solution or alternative to them. And you would be right.

So we won’t disappoint you and will end the suspense now: there are indeed solutions, that we provide with Extradium for SharePoint. But we also believe that a problem must be properly and clearly delineated first before a solution can be suggested. Otherwise, the solution will appear as being completely out-of-context and thus irrelevant.

If you’re interested in knowing how Extradium solves those limitations, please contact us and we’ll be happy to arrange a demo!

by