Standard roles

Introduction

This section provides an information on how to use standard roles in EPiServer Commerce. Depending on which authentication model you are working with, there are some small differences in how to work with roles which is highlighted later. The EPiServer Commerce sample site has a number of roles, both for managing editorial content as well as for administering the e-commerce tasks. It is important to note that roles can be virtual roles which can combine mutiple roles into one role.

Administering security and access rights

When you administer access rights you will use some distinct components that are tied very loosely together. The components are as follows:

• Users
• Roles
• Access control lists (ACLs).

An ACL is simply a list of SecurityEntities and an access level. The security entity is a name and information stating if the name represents a role or a user. Once you have a security entity in an ACL, it will not be affected by changes in roles or role membership. One aspect of this is that when you delete a role and then look at an ACL that had an access entry for this role, the role will still be displayed in the ACL.

Commerce-specific virtual roles

In addition to the default EPiServer groups (WebAdmins, WebEditors etc.), Commerce has a set of specific virtual roles that can be used for controlling access to parts of the user interface.

• CommerceAdmins - provides access to the Commerce Manager back-end system (but not the administration view in EPiServer).
• CommerceSettingsAdmins - provides access to Settings menu for administering for instance dictionary values.
• CatalogManagers - provides access to the Catalogs user interface.

These virtual roles are configured in EPiServerFramework.config, for example:

<add name="CommerceAdmins" type="EPiServer.Security.MappedRole, EPiServer.Framework" roles="WebAdmins, Administrators" mode="Any" />

Forms authentication model

To work with roles in the forms authentication model we work with The AspNet RoleProvider. Below are examples of how to configure the role provider and check if a user is a role.

<roleManager enabled="true" defaultProvider="WindowsRoleProvider"> 
   <providers>
      <clear />
      <add name="MultiplexingRoleProvider"
         type="EPiServer.Security.MultiplexingRoleProvider, EPiServer"
         provider1="SqlServerRoleProvider"
         provider2="WindowsRoleProvider"
         providerMap1="SqlServermembershipProvider"
         providerMap2="WindowsMembershipProvider" />
      <add name="WindowsRoleProvider"
         applicationName="EPiServerSample"
         type="EPiServer.Security.WindowsRoleProvider, EPiServer" />
      <add name="SqlServerRoleProvider"
         connectionStringName="EPiServerDB"
         applicationName="EPiServerSample"
         type="System.Web.Security.SqlRoleProvider, System.Web, 
            Version=4.0.0.0, Culture=neutral, 
            PublicKeyToken=b03f5f7f11d50a3a" />
   </providers>
</roleManager>

To add a role, add user to role, or check if user is in role use the following code snippets.

Roles.CreateRole(roleName);
Roles.AddUserToRole(username, roleName);
var isInRole = Roles.IsUserInRole(username, roleName);
var roles = Roles.GetRolesForUser(userName);

OWIN authentication model

Working with roles in owin we need to create claims for the user the map to roles they are associated with. Below are some examples of working with claims

//Create identity with the following roles Everyone, Authenticated, Registered
var claims = new List()
{
    new Claim(ClaimTypes.Name, userName),
    new Claim(ClaimTypes.Role, "Everyone"),
    new Claim(ClaimTypes.Role, "Authenticated"),
    new Claim(ClaimTypes.Role, "Registered"),
};
var claimsIdentity = new ClaimsIdentity(claims, "ApplicationCookie");
HttpContext.Current.GetOwinContext().Authentication.SignIn(new [] { claimsIdentity });

//Check if current user is in role
var isInRole = EPiServer.Security.PrincipalInfo.CurrentPrincipal.IsInRole(rolename);