Security

In this section, you learn about Sitefinity scenarios related to security and authentication. You will see how to implement an ASP.NET SQL provider to login to the Sitefinity backend. Then you will learn how you can create a custom membership provider to let users authenticate to Sitefinity CMS using an external database or service, a scenario that also lets you customize the notification email sent to users that asked to reset their password.

Sitefinity supports the standard ASP.NET membership APIs, detailed in the MSDN article MembershipProvider Class. Once you have your membership provider, register it in the web.config file, as described in the MSDN article Configuring an ASP.NET Application to Use Membership. When working with the standard ASP.NET membership APIs, the Sitefinity blog article Using the ASP.NET Sql Membership Provider in Sitefinity provides Sitefinity-specific details on creating and registering your custom ASP.NET membership providers.

There are, however, limitations to this provider such as performance issues in querying users. The standard membership APIs provide only the method GetAllUsers(int page, int pageSize, out totalRecords) for querying users.  While this might be adequate for systems with a constrained number of users, when the user base becomes very large, any filtering and sorting of the collection of users requires loading all the users into memory, and then applying the filtering and search algorithms there.  That behavior could result in  memory management issues as well as performance degradation.

Sitefinity offers a workaround for this limitation: If you want to optimize your ASP.NET SQL membership provider (or any other membership provider that inherits from the standard ASP.net membership APIs) in Sitefinity, implement a custom membership provider.

Sitefinity has its own base MembershipDataProvider class that does not inherit from the ASP.NET membership provider. Instead it provides an abstraction to persist and query the users and roles into the Sitefinity database, and avoids the limitations in the standard Membership Provider APIs.  The following diagram illustrates the provider’s classes:

The MembershipDataProvider class implements the standard CRUD operations in a unified interface for accessing users. This class also has a GetUsers method that returns an IQueryable<User>. That’s how you filter and sort user data.

The MembershipDataProvider class has two inheritors:

• OpenAccessMembershipProvider
  Uses Telerik DataAccess ORM to and works with a table in the database (sf_users) that holds the users for the current application. The default provider that Sitefinity uses is described in the Create a custom membership provider article. This provider is similar to the default one used in the backend (OpenAccessMembershipProvider), but provides a different implementation of the MembershipDataProvider class that is similar to the default one, yet customized to provide the GetUsers method that returns the IQueryable<User>. By implementing MembershipDataProvider base class, you do not need to enhance this provider using the sample in GitHub unless you want additional functionality.
• MembershipProviderWrapper
  Used when the user registers a membership provider built with the ASP.NET membership provider APIs. This provider inherits from MembershipDataProvider, but holds the internal instance of the MembershipProvider registered in the web.config file. This way the wrapper forwards every method call to the underlying membership provider.

NOTE: Only the methods of the base provider are called by the system, so the system does not know which provider is currently in use -- it just knows about the abstract MembershipDataProvider.