Implementing a custom membership provider for EPiServer, part 1

There are a lot of pages out there describing the basics of a .NET custom membership provider, while others describe configuring a ready-made custom provider for EPiServer. Here's a two-part tutorial that combines this info into a practical example.

Part 1 introduces the basic concept of a membership provider. Jump to part 2 for the technical stuff.

• Why implement a custom membership provider?
• How does a membership provider work?
• How does EPiServer interact with the membership providers?
• The technical stuff

Why implement a custom membership provider?

You'll need a custom membership provider if:

• you want to store users in a table schema that differs from the default .NET Membership tables structure
• you want to separate certain users (e.g. customers) from others (e.g. admin/editor accounts)
• you want to store users in a non-SQL/database/file system (RavenDB/MongoDB, Oracle, flat file, etc)
• you have an existing membership system (e.g. from another CMS) that you want to plug into EPiServer

How does a membership provider work?

A membership provider offers a set of methods for retrieving, adding, updating, authenticating and deleting user accounts. The providers that ship with .NET use Stored Procedures (prefixed "dbo.aspnet_Membership_") to interact with SQL Server database tables (prefixed "dbo.aspnet_")

  
Above: The default .NET Membership tables.

Above: The default .NET Membership Stored Procedures.

How does EPiServer interact with the membership providers?

EPiServer is built on the .NET Membership model and uses the active membership providers for interaction with database/storage. For instance, the "Search Users/Groups" feature in EPiServer admin mode uses provider methods to retrieve and interact with user accounts (here shown using the SqlMembershipProvider which ships with EPiServer/.NET):

Above: Flowchart using a .NET Membership provider.

Note that EPiServer will call different provider methods depending on the input in the search fields:

• Name field = FindUsersByName method
• E-mail field = FindUsersByEmail method
• All fields blank = GetAllUsers method

When searching, EPiServer will call these methods on all active providers, one by one. This means that the search will fail with a "Method not implemented" error if one of the providers does not support the method in question. So if you want to let EPiServer handle your users, make sure you implement all the methods required.

The "Edit User" screen also uses several common provider methods that you might want to include in your custom provider:

Provider methods and attributes required for this feature to work properly:

The technical stuff

In part 2, we'll create a simple custom SQL-based membership provider.