Inherit from DataProviderBase

Secured providers must inherit from DataProviderBase. It has several important members that you should be aware of.


Return the security root of the permissions inheritance. It is responsibility of the decorator to implement this.


Override to customize the permission sets used by your provider.


Sets default permissions (using the general permission set). Reasonable defaults are set: everyone is allowed to view items and backend users are allowed to create and delete.

If the security root supports comments, everyone will be allowed to create and view them, but only backend users will be able to delete and modify.

Use the following sample to override it:


Returns a cached instance of the security root. You should not have reasons to override this in you modules.


If secured object and permission are created in different providers, this will use a common transaction to safely add a permission to the secured object. You don't need to override this, as this is responsibility of the decorator.


Gets the all the secured objects which inherit permissions, through permissions hierarchy, from a secured object.


Gets a dictionary:

  • Key is a name of a permission set supported by this provider
  • Value is a resource key of the SecurityResources title which is to be used for titles of permissions, if defined in resources as placeholders.
Usage of this property is covered in detail in the topic for permission labels.

Apply security attributes to methods that perform CRUD operations

Security-related attributes will be discussed in greater detail, but here is an overview on how you should apply them in your providers: PermissionAttributes#SampleUsage

The general idea is that you have to map provider methods to security actions, this informing Sitefinity CMS what permissions to check when certain methods are invoked.

NOTE: You probably noted the CommitTransaction override. While we don't add any functionality, we add a new attribute. Sitefinity CMS works in transactions, and certain permissions checking is possible at transaction commit time only (e.g. modify).

IMPORTANT: Methods that have attributes applied on them should be virtual. Sitefinity CMS security engine uses method interception, and for this to work, your classes are overriden in dynamic modules. If your methods are not virtual, the IoC framework we use wouldn't be able to override them, thus interception won't work. As a result of this, security (automatic demanding)will not be applied.

In the delete method of a data provider, the developer should call this code:

While this is implemented for the core static modules, you should handle it in your types so that the table sf_permissions_inheritance_map can avoid being flooded with unused ids.

Increase your Sitefinity skills by signing up for our free trainings. Get Sitefinity-certified at Progress Education Community to boost your credentials.

Get started with Integration Hub | Sitefinity Cloud | Sitefinity SaaS

This free lesson teaches administrators, marketers, and other business professionals how to use the Integration hub service to create automated workflows between Sitefinity and other business systems.

Web Security for Sitefinity Administrators

This free lesson teaches administrators the basics about protecting yor Sitefinity instance and its sites from external threats. Configure HTTPS, SSL, allow lists for trusted sites, and cookie security, among others.

Foundations of Sitefinity ASP.NET Core Development

The free on-demand video course teaches developers how to use Sitefinity .NET Core and leverage its decoupled architecture and new way of coding against the platform.

Was this article helpful?