Universal Provider Framework For SharePoint Theory Of Operation

Download Visual Studio Project File

Object Model Documentation – View Online

SharePointMembershipProvider.cs – View Online | Download Class File

SharePointProfileProvider.cs – View Online | Download Class File

SharePointRoleProvider.cs View Online | Download Class File

SharePointUsersProvider.cs – View Online | Download Class File

GeneralUtilities.cs – View Online | Download Class File

UserData.cs View Online | Download Class File

As stated in other articles, SharePoint 2007 ships with two default providers, one for SQL, and one for Active Directory. However, what if you wanted to build your own membership and role provider for an arbitrary database system such as Informix, DB2, Oracle, mySQL, or any number of tabular based membership systems that a membership provider could support. The development task can just prove arduous, and can be rather boring. The releases on MSDN regarding implementing providers leaves something to be desired, especially if you are looking to get something off the ground quickly, efficiently, and with as little coding as possible. The Universal Membership Provider provides the most generic, easy to manipulate framework for universal data access to your membership, role, and profile data stores all by making small changes to how the framework talks to your backend data store (several database structure are already defined on this site). Afterwards, some small changes are made to the web.config either by directly editing or using the Provider Metadata Manager, and then setting up the provider settings within your WCAM environment.

The Universal Provider framework solves this dilemma by providing a generic basis whereby the only portion that you are responsible for is placing the format specific database queries into the solution file, built, and fill out the relevant setting in your web.config either through direct editing or through using the Universal Membership Provider metadata manager client application.

The Universal Provider framework is composed of two main portions. One if the generic basis that requires you to enter in the specific database query for how SharePoint will interact with a custom database in order to find, assimilate, and leverage the tables provided in it. The second portion of the application is a management file for those that wish to have an easy to use interface into their web.config file that will allow them to apply there membership provider settings and view other relevant information that is stored in it through a simple format.

The purpose of the Universal Provider Framework is a relatively simple one. It provides a layer of abstraction and all of the relevant methods needed in order to procure the needed functionality for membership, role, and profile features from an arbitrary database that you define to bind to your MOSS environment. The only requirement that you need is to know the database query language that you are using in order to harvest the relevant information out of the database that you want to use.

This is done by leveraging database factory patterns as define by the .NET framework, which can be spilt into both abstract factory structures and our relevant factory pattern, the ADO.NET 2.0 factory pattern. The abstract factory pattern is basically a factory object that returns one of several groups of arbitrary, undefined classes. So in essence, we are not restricted to defining the tangible base classes since the factory object will define an interface for our objects.

The portion that the Universal Provider framework is dependent on are the abstract factory classes that will define a layer for various types of data providers, which will allow us access to various types of membership stores while keeping a layer of abstractness. The DbProviderFactory is an abstract factory class (as shown in the above diagram) which will define all of the relevant methods that we need in order to connect and massage our provider independent data member store. The abstract class pattern framework can simply be defined as keeping things with as little ties to a specific platform as possible. This has several advantages over use concrete factories, mostly in that we will be isolating the framework from implementation classes since the framework will instead massage instantiation from the abstract interface, we can easily switch to different database systems since the configuration for the concrete factory appear solely where we are instantiating it, and we can have objects that are deriving from various families called at a single time, since the ConcreteFactory classes will allow the creation of objects that will have a distinct implementation type.

In this, we are introducing a layer of ambiguity. However we can still introduce the concept of concrete factory classes that are instead bound to a specific data provider, such as ConcreteFactory which will create concrete specific objects, and ConcreteProduct, which will define the actual product objects that are generated by the ConcreteFactory. If this is the case, all the methods that the framework will use will then specific to that database platform.

We can see fro the combined explanations thus far that we are not locking into a specific provider, can in fact hook into multiple providers. The important overall concept to understand is that DBProviderFactory will allow an abstract base call that we can independently provide implementation for. We can obtain the independent provider by implement the static method GetFactory out of DbProviderFactories which will simply assimilate a string. The GetFactory method provides two overloads

  • GetFactory(String) – takes an invariant name, such as "System.Data.OracleClient." (demonstrated in code below)
  • GetFactory(DataRow) – takes a reference to a row in the DataTable returned by the GetFactoryClasses method

In regards to the concrete versions of the DbProviderFactory are provided within your machine.config file by default each which is simply going to allow the invocation of any number of family type classes. The structure of where these reside in the machine.config file appears as such:

< system.data >
< DbProviderFactories >
< add name="SqlClient Data Provider"
description=".Net Framework Data Provider for SqlServer"
type="System.Data.SqlClient.SqlClientFactory, System.Data,
Version=2.0.3600.0, Culture=neutral,
PublicKeyToken=b77a5c561934e089" / >
< add name="Odbc Data Provider"
support="BF" description=
".Net Framework Data Provider for Odbc"
type="System.Data.Odbc.OdbcFactory, System.Data,
Version=2.0.3600.0, Culture=neutral,
PublicKeyToken=b77a5c561934e089" / >
< /DbProviderFactories >
< /system.data >

The following invariants should natively appear within the machine.config file:

  • System.Data.Odbc.OdbcFactory
  • System.Data.OleDb.OleDbFactory
  • System.Data.OracleClient.OracleClientFactory
  • System.Data.SqlClient.SqlClientFactory

If you wanted to enumerate through these without dipping into the web.config file, you could simply place the following statement and bind it to a datatable in a WebPart:

Because of these offerings, each of these is very easy to register in C#:
DbProviderFactory provider = DbProviderFactories.GetFactory("System.Data.OracleClient");

For the specific factory methods that are used, there are several public ones that will create the relevant objects since the providers are not yet defined, each returning an abstract class:

  • CreateCommand – Returns a new instance of the provider’s class that implements the DbCommand class.
  • CreateCommandBuilder – Returns a new instance of the provider’s class that implements the DbCommandBuilder class.
  • CreateConnection – Returns a new instance of the provider’s class that implements the DbConnection class.
  • CreateConnectionStringBuilder – Returns a new instance of the provider’s class that implements the DbConnectionStringBuilder class.
  • CreateDataAdapter – Returns a new instance of the provider’s class that implements the DbDataAdapter class.
  • CreateDataSourceEnumerator – Returns a new instance of the provider’s class that implements the DbDataSourceEnumerator class.
  • CreateParameter – Returns a new instance of the provider’s class that implements the DbParameter class.
  • CreatePermission – Returns a new instance of the provider’s class that implements the provider’s version of the CodeAccessPermission class

All methods that a SharePoint administrator should be concerned about are handled through the Universal Provider framework. The ones that are currently built in handle both the membership and role provider for an arbitrary database system.

Inventory of Universal Membership Provider:

  • Creating Users
  • Deleting User
  • Verify Login Credentials
  • Change User Passwords
  • Resetting User Passwords
  • Updating Membership Parameters
  • Native Reading off config file for password strength attributes
  • Decoding / Encoding Passwords (Natively Hashing Passwords Through The Machine Key or Defaulting To the .NET Hash Algorithm)
  • Finding/Getting Users by Email
  • Finding/Getting Users by Name
  • Finding/Getting Membership By Username
  • Finding/Getting All Users For The Provider
  • Unlocking User Accounts
  • Valdiating Various User Parameters
  • Writing Events to the Application Event Log
  • And More!

Inventory of Universal Role Provider:

  • Creating Roles
  • Deleting Roles
  • Adding Users to Roles
  • Removing Users from Roles
  • Finding/Getting Specific/All users in specific roles
  • Finding/Getting roles for specific users (determining user roles)
  • determining what roles exist
  • determining if entered users exist
  • Writing Events to the Application Event Log
  • And More!

Inventory of Universal Profile Provider:

  • Profile data encoding/decoding
  • Deleting Inactive/Active Profiles ( profile existence)
  • Finding/Getting Inactive/Active Profiles By Username,
  • Finding/Getting All Inactive/Active Profiles
  • Getting the number of Inactive Profiles
  • Getting/Setting relevant property values
  • Writing Events to the Application Event Log
  • And More!