No image

4 major limitations of the SharePoint People Picker when used with Forms-Based Authentication – Part 2

If you haven’t already read Part 1 of this blog series, I strongly encourage you do now.

As I wrote at the end of Part1, User Confidentiality and Segregation is by far the least well known and most challenging aspect of the People Picker when used with Forms-Based Authentication.

The main issue at stake revolves around the following business requirement: if and when external users come to use the SharePoint People Picker, they should be restricted to only see and select “authorized” users.

Of course, defining what an “authorized” user is varies from one organization to another. In practice, most organizations will first define which users external users should NOT be able to see (“invisible” users), and then which users they should be able to see (“visible” users).

In the most common cases, “invisible” users should be:

  1. Other external users working for different customers, partners, vendors, etc… This is the most common requirement when dealing with external sharing and one that is very poorly addressed by most SharePoint FBA solutions.
  2. Internal Windows users, or at least Windows users whom they don’t collaborate with on an external site.

Conversely, external users should most commonly be able to see:

  1. Their own colleagues (as external users)
  2. Internal users whom they work with
  3. Other external users they have to collaborate with (for instance in a scenario where a single company works with multiple vendors on a project where all the vendors must work together)

Factoring in all those requirements is a challenging task that in most cases impacts information architecture choices (such as creating separate site collections instead of secured sub-sites for each partner/customer), and accommodating all of these requirements can sometimes be next to impossible.

It is also true that in most cases external users will not use the People Picker in the context of the Site Permissions page (to add or remove users to a site) but more commonly in “Person or Group” fields on document libraries or lists (such as a Tasks list). In a “Person of Group” field scenario, there are ways to alleviate confidentiality concerns, because such “Person or Group” fields can be restricted to only pull users from a specific SharePoint group in the current site. However, this can be impractical in the long run because:

  1. In many cases, you will only want to use that SharePoint group for the purpose of user filtering (and not security) and you might end up with multiple such groups if you have many different “Person or Group” fields scattered across different site collections or sub-sites
  2. You have to add each and every new Windows or FBA user to that group whenever necessary
  3. All in all, this can result into a governance and management nightmare

The People Picker does provide some configuration options that can be used to limit which users are visible and which are not. You can find more information about such configuration options at but we find that those configuration options are overall limited, especially in an FBA scenario. More specifically:

  1. Most configuration options apply to Active Directory search filtering or Organizational Unit visibility restrictions, and only when used with Windows Authentication, not Forms-Based Authentication
  2. Some of the more interesting configuration options, such as Peoplepicker-onlysearchwithinsitecollection are overly restrictive: they will apply to the whole web application, regardless of the zone and will apply to all types of users, whether they are site collection administrators or regular users. Adding new users to a site is thus impossible other than by using custom code since the People Picker will only return users already in the site collection, not any new user in the underlying user repository.

Overall, the specific limitations of the People Picker in preserving user confidentiality and segregating users within distinct entities in an FBA environment are the following:

  1. When not restricted to a specific SharePoint group (or users in the current site collection), the People Picker relies entirely on the underlying ASP.NET membership provider to return the list of potential matches.
    If the ASP.NET membership provider is not able to filter the list of matching users based on the identity of the current user (which is the case for most membership providers, with the notable exception of the Extradium provider), a breach of user confidentiality can very easily occur.
  2. As mentioned above, although it is possible to restrict user searches only to users in the current site collection, this is often impractical because no additional user can be added to a site, unless a custom code and/or user interface are developed to add new users, since even site collection administrators are affected by this restriction, on all zones of the web application.


So where does that leave us? Clearly, the standard SharePoint People Picker is ill-suited for extranet scenarios because it does not include the multi-tenant security features that are critical to ensuring that the identity of both internal and external users is preserved. In future blog posts, I will explore how Extradium for SharePoint fills those security holes and provides an innovative and effective solution to ensure that your SharePoint extranet provides value to your external users while preserving the identity and confidentiality of both your internal and external users.

facebooktwitterredditlinkedinmailby feather