Standard roles

This topic describes 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 are highlighted later. The Episerver Commerce sample site has a number of roles, both for managing editorial content and for administering the e-commerce tasks. Roles can be virtual roles which can combine mutiple roles into one role.

Administering security and access rights

When you administer access rights, you use the following distinct components that are tied loosely together.

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

  An ACL is a list of SecurityEntity classes 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 is not 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 is still displayed in the ACL.

Commerce-specific virtual roles

In addition to the default Episerver groups (WebAdmins, WebEditors, and so on), 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, work with The AspNet RoleProvider. The following examples show 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, create claims for the user the map to roles they are associated with. The following examples shows 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)
;