Permissions to functions
Introduction
EPiServer has a built-in system for assigning permissions to individual functions. Assigning users and roles to a permission can be done in the administrative interface under Config->Permissions to functions. Built-in permissions include the ability to access web services and viewing detailed exception messages.
Using permissions to functions
The API for querying if a user is permitted to perform a function is available via EPiServer.Security.PermissionService or via PrincipalInfo as a simplified API.
//Alt 1
bool hasPermission = ServiceLocator.Current.GetInstance<PermissionService>().IsPermitted(HttpContext.Current.User, SystemPermissions.DetailedErrorMessage);
//Alt 2
bool hasPermission = PrincipalInfo.Current.IsPermitted(SystemPermissions.DetailedErrorMessage);
Define permissions to functions in code
It is possible to define custom permissions to functions by defining a class, see example below. Classes with the PermissionTypes attribute will automatically be picked up by EPiServer and made visible in the administrative interface. Permission names must be unique within a group, so take great care picking a group name that is unique to your particular solution. It is also possible to register permission types via EPiServer.DataAbstraction.PermissionTypeRepository to support dynamic creation of permissions.
[PermissionTypes]
public static class MyCustomPermissions
{
public const string GroupName = "MyCustomPermissions";
static MyCustomPermissions()
{
EditSettings = new PermissionType(GroupName, "EditSettings");
ViewSettings = new PermissionType(GroupName, "ViewSettings");
}
public static PermissionType EditSettings { get; private set; }
public static PermissionType ViewSettings { get; private set; }
}
It is possible to define readable descriptions for the group and the permissions that will be shown in the user interface by adding an entry to a language resource file as shown below. The pattern is that under groups node should there be a node named as the GroupName for the permission. Under that node should their be a description and under the permissions node should there be nodes named as the permission names.
<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<languages>
<language name="English" id="en">
<admin>
<permissiontype>
<groups>
<MyCustomPermissions>
<description>Custom settings fuctions</description>
<permissions>
<EditSettings>Allows users to access edit settings</EditSettings>
<ViewSettings>Allows users to access view settings</ViewSettings>
</permissions>
</MyCustomPermissions>
</groups>
</permissiontype>
</admin>
</language>
</languages>
Protecting a controller via a permission
The AuthorizePermission attribute can be used to authorize a MVC controller via permissions to functions:
[AuthorizePermission("MyCustomPermissions", "EditSettings")]
public class EditSettingsController : Controller
{
public ActionResult Index()
{
return View();
}
}
Using virtual roles to expose permissions to other systems
Some systems can not validate permissions but are able to validate roles, in these cases it might be useful to expose a permission as a role:
[InitializableModule]
[ModuleDependency((typeof(EPiServer.Web.InitializationModule)))]
public class VirtualRoleInitializer : IInitializableModule
{
public void Initialize(InitializationEngine context)
{
var virtualRoleRepository = VirtualRoleRepository<VirtualRoleProviderBase>.GetDefault();
virtualRoleRepository.Register("EditSettingsVirtualRole", new PermissionRole
{
Permission = MyCustomPermissions.EditSettings
});
}
public void Uninitialize(InitializationEngine context) { }
public void Preload(string[] parameters) { }
}
Do you find this information helpful? Please log in to provide feedback.
Last updated: Feb 23, 2015