Area:
Permissions to functions
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.
Code samples in this article is based on the improvements introduced in CMS 7.19. The virtual role and the MVC attribute is not supported in older versions, you are only able to check if a user is permitted a specific function by using the now obsoleted EPiServer.DataAbstraction.PermissionData class and the user interface was not extendable.
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) { }
}Last updated: Dec 15, 2014
