Loading...
Area: Episerver Commerce
Applies to versions: 10 and higher
Other versions:

Authorization and authentication

Recommendations [hide]

This topic describes the authentication and authorization model in Episerver Commerce, which uses the default membership and role system in ASP.NET. You configure membership and role providers in the website's web.config file. The Episerver Commerce sample site has several predefined users, groups, and roles for managing content and administering Commerce tasks.

Terminology

Authentication and authorization are used by the system to identify users and user groups, and determine what they are allowed to do. Here are common terms used in this context:

  • Authentication. The process of identifying a user. Typically done via username and password.
  • Authorization. The process of determining actions a user is allowed to perform.
  • Provider. A module called by ASP.NET to provide an underlying service.
  • Membership provider. The module that handles authentication in the ASP.NET security model.
  • Role provider. The module that gives the base data for authorization in the ASP.NET security model.
  • Profile provider. The module that stores and retrieves personalized data in ASP.NET.

Administering security and access rights

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

  • Users. Delivered by the current membership provider.
  • Roles. Delivered by the current role provider and the virtual 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 whether the name represents a role or a user. A security entity in an ACL is not affected by changes in the membership or role provider. So if you delete a role and then look at an ACL that had an access entry for this role, it still appears in the ACL.

    Membership providers have APIs for creating, editing and deleting users. The SQL membership provider lets you modify the user database, while the Windows membership provider does not.

Commerce-specific virtual roles

In addition to the default EPiServer groups (WebAdmins, WebEditors, and so on), Commerce has virtual roles that you can use to control access to parts of the user interface.

  • CommerceAdmins. Access to all parts of Commerce except Administration and CMS admin view.
  • CommerceSettingsAdmins. Access to Settings menu for administering, for instance, dictionary values.
  • CatalogManagers. Access to the Catalogs user interface.
  • MarketingManagers. Access to the Marketing user interface.
  • CustomerServiceRepresentatives. Access to the Order management screen.

These virtual roles are configured in EPiServerFramework.config. For example:

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

Note: MarketingManagers group users also have access to the CMS editing user interface by default. To restrict this group's ability  to edit content, limit access via the Admin view > Set Access Rights screen. Here, grant "Read" access to MarketingManagers.

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 assigned a role.

To add a role, add a user to role, or check if a user is assigned to a 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 to map to roles they are associated with. The following example shows working with claims.

Related topics

Do you find this information helpful? Please log in to provide feedback.

Last updated: Mar 21, 2019

Recommendations [hide]